Why should we emphasize independent test case? (Update)

In the test case writing mode, there are two opposite cases in the case organization mode.: Chained Test CasesAndIndependent Test Case, Chained test case indicates that the previous test case is execution successful, which is the precondition for execution of the next test case,Independent
Test CaseIt means that the above dependency relationship should not exist before the case. I strongly recommend it here.Independent Test CaseWhy?

 

Let's take a look at the example below. HereChainedtestcase2Depends onChainedtestcase1Is successfully executed

 

Then followIndependent Test CaseThe test case should be rewritten as follows:

 

 

After this rewrite, I heard two of the most complaints:

LPoor readability, and a case becomes very long;

LEase of use deteriorated, because a test log will become long, making it difficult to locate the problem.

 

To solve the first readability problem, we can introduce another layer (test process layer) of sub-assembly to solve the problem. The case will be rewritten to something like this (add-on, according to the feedback from @ yundao tianxiao, how should we implement this test process layer? The following example just shows a diagram. We can further abstract and reconstruct the layer or even form a DSL, which is not discussed in this blog)

 

  

After the preceding reconstruction, the readability problem can be solved, but the log length problem is not solved. In fact, this problem should be solved by the test framework. For example, inRobotframeworkIn the Framework, it uses multi-level CascadeHtmlFormat, which can be used to locate logs, as shown in

 

In fact, I have seen manyJavaOfSeleniumThe test framework is relatively weak in logs. Let's talk about it in the future.

 

Now let's take a look at the advantages of an independent test case after reconstruction compared with two highly dependent test cases? We can useMerestThe principle is as follows:

LThere is no difference between the two methods for essential indicators, sensitivity and reliability;

LIn terms of efficiency, an independent case is superior. However, in some enterprises or teams, for leaders who do not know how to do so, more test cases are also a political need, this is another case; in terms of execution efficiency, an independent case will be stopped immediately after an error occurs, and the two strong dependent cases will be stopped immediately after the previous case fails, you also need to find a way not to let the next case be executed, increasing the extra complexity;

LFor readability, it is better to add an independent case of the test process layer;

LFor ease of use, if all cases are independent cases, you can check the test report to see if there are any cases that fail. If you select a failure case, you can re-run it immediately. For highly dependent tests, we need to analyze the cases that have failed and the cases that have failed in the previous cases;

LFinally, for maintainability, when refactoring, expansion, and addition of independent cases, there is no need to consider the associations between cases, which is more advantageous.

 

Chained test caseThe biggest problem is that it violatesCodeThe high cohesion and low coupling principle, in the original concept of coupling (test case, method) should not appear manually added coupling, it seems that short-term saving effort, however, the cost will be higher in the long term.

 

To sum up, when there is a strong dependency between the two so-called cases, it is better to merge them into one case to maintain the independence of the case.

 

Although the strong dependence case is still an independent case, it seems to be a small problem. However, if you do not stick to some principles, the building in the automated test case will gradually collapse.The next question worth discussing is whether it is worthwhile to divide an independent case into two independent cases when the process of an independent case is long. This is a case granularity issue that I will discuss in the next blog.