为什么要强调Independent Test Case？(更新）

在测试案例编写模式，有关案例组织有两种对立的模式: Chained Test Cases和Independent Test Case，Chained Test Case是指前一个测试案例是执行成功是后一个测试案例执行的前置条件，Independent Test Case是指案例之前不应该有上述依赖关系，在这里我强烈推荐Independent Test Case，下面我解释一下原因？

 

让我们看下面的例子，这里ChainedTestCase2会依赖ChainedTestCase1的执行成功

                             

 

那么按照Independent Test Case模式，测试案例应该初步改写成如下：

 

 

这样改写之后，我听到最多的抱怨有两个：

l  可读性变差，一个案例变得很长；

l  易用性变差，因为一个测试日志会变得很长，不利于问题定位

 

对第一个可读性问题，可以通过再引入一层（测试流程层）分装来解决，案例会改写成类似这样（加注，根据@横刀天笑兄弟的反馈，说明一下，这个测试流程层应该怎么来实现，下面例子只是给出一个示意，后续可以进一步抽象重构，甚至形成一层DSL，这个就不在这篇博客里面讨论了）

 

  

进过上述重构，可读性的问题应该可以得到解决了，但是，日志长的问题并没有得到解决。其实这个问题应该由测试框架来解决，例如，在RobotFramework框架里面，它是使用可以多级级联的HTML格式，可以很好地解决日志定位问题，如下图所示

 

其实目前我看到的很多基于Java的Selenium测试框架在日志方面都比较弱，这个未来另文叙述吧。

 

现在我们来看一下，重构之后的一个独立测试案例相对于两个强依赖测试案例，有什么优势呢？我们可以用MeReST原则来分析一下：

l  对于必备指标，敏感性和可靠性而言，这两种写法没有区别；

l  从高效性来讲，一个独立案例会更胜一筹，但是，在某些企业或团队，对不懂行的领导而言，测试案例多一些也会是一种政治需要，这就另当别论了；另外，从执行效率而言，一个独立案例出错后，马上就会停止，而两个强依赖案例，在前一个案例失败后，还需要想办法不让后一个案例执行，增加额外复杂性；

l  对于可读性而言，增加了测试流程层的一个独立案例还是会更好一些；

l  对于易用性来讲，如果所有案例都是独立案例，一看测试报告就知道有没有案例失败，选择失败案例，马上就可以重跑；而对于强依赖测试而言，就还需要再分析一下，哪些案例是真的失败了，哪些案例是由于前面案例执行失败造成的；

l  最后对于可维护性而言，独立案例在重构、扩展、新增时，不需要考虑案例之间的关联性，更有优势。

 

Chained Test Case的最大问题在于它违反了代码的高内聚，低耦合原则，在原本不应该出现耦合的概念（测试案例，方法）人为又增加了耦合，看起来短期省了力气，但是长期会付出更大的成本。

 

综上所述，当两个所谓的案例之前存在强依赖关系时，还是把它们合并到一个案例里面为好，以保持案例独立性。

 

虽然，强依赖案例还是独立案例，这看起来是个小问题，但是，千里大堤毁于蚁穴，如果不坚守一些原则，自动化测试案例的大厦就会逐步崩溃倒塌了。下一个值得讨论的问题是当一个独立案例流程长时，是否值得把它分成两个独立的案例呢，这是一个案例粒度问题，我将在下一篇博客里面来讨论。