Xunit test patterns Study Notes 4-Principles of test automation

There are some basic principles in the automated testing process, just like manifesto ). Because most of the Principles are mentioned above, some do not explain much.

Principles:Write the tests first

Principles:Design for testability

Principles:Use the front door first

It means that the test starts from the publish method exposed on the outermost layer.

Principles:Communicate intent

This means that the test case should be clearly illustrated so that it is easy to understand and maintain. For example, when naming, use intent-revealing Names [sbpp]. Reference: http://architects.dzone.com/news/intention-revealing-designs

Principles:Don't modify the SUT

Do not modify the objects to be tested. However, when using some test double or fake objects, note that each alternative object is tested. For example, there are three modules X, Y, and Z. x depends on Y and Z, and y depends on Z. When testing X, you can use test double instead of Y and Z, when testing y, you can use test double instead of Z. However, when testing Z, you cannot replace Z with test double Because Z is the object to be tested.

Principles:Keep tests independent

Independent test cases, independent execution, and independent from other cases.

Principles:Isolate the SUT

Make SUT independent and independent from external environment. Sut often depends on other external environments, such as relying on an external application.ProgramDepends on an available HTTP server. This makes the test unstable or slows down the execution speed. The method to remove SUT dependencies is to replace the external factors with test double. For example, if you need an HTTP server, you can build a fake HTTP server.

Principles:Minimize test overlap

Minimize repeated tests. We know that the combination of test cases is endless and we cannot cover all the combinations. But we can choose the best combination. To be testedCodeIt makes little sense to repeat the test under the same condition.

Principles:Minimize untestable code

Minimize untestable code by restructuring it!

Principles:Keep test logic out of production code

As mentioned in the previous section, do not add any test logic to the product code. For example, such as if tesing.

Principles:Verify one condition per test

In the process of interpretation, it is interesting to have a point of view. During manual testing, complex operations and complex conditions are combined to check whether errors occur. This seems to be the opposite of automated testing or unit testing. Why? This is because people can judge various execution results under Complicated Circumstances and analyze the problems. Our cases are actually not so intelligent. In order to make the cases more accurate to locate the problem, we can only check one case for each case.

Principles:Test conerns separtely

For the explanation of separation of concerns, see: http://en.wikipedia.org/wiki/Separation_of_concerns

This probably means that the test cases should be well layered to reduce duplicates, making it easier to locate problems.

Principles:Ensure commensurate effort and responsibility

The time for writing and maintaining test cases cannot exceed the time for product code implementation. Therefore, we need to balance the efforts of testing and development.