Xunit test patterns Study Notes 2-goal of test automation

ArticleDirectory

• Goals of Automated Testing

Some people may think unit testing is dispensable, because they feel that they need to put too much effort and customers do not need it. This involves the issue of ROI. In fact, the investment used for testing often gains more returns. It reduces the number of bugs and debugging.CodeThe time when the bug was found. See the time chart for testing and development efforts with an effective investment in automated testing:

In the early stage, with the intervention of the test, the development investment is gradually reduced. In the later stage, with the improvement and automation of test cases, the investment required for testing and development was reduced to a very low level. The Shadow part saves development investment.

At the same time, if the automated test is not well performed, it may increase the burden of testing and development in the future:

 

Goals of Automated Testing

1. Tests shocould help us improve quality.
2. Tests shoshould help us understand the SUT.
3. Tests shocould reduce (and not introduce) risk.
4. Tests shoshould be easy to run.
5. Tests shoshould be easy to write and maintain.
6. Tests shoshould require minimal maintenance as the system evolves around them.

Tests shocould help us improve quality

1. The tests as specification Test Case can verify the Product Behavior and whether the "Building the right software"
2. The main purpose of bug repellent automated testing is not to discover bugs, but to prevent or prevent the emergence of bugs.
3. The customer tests at the top-level of defect localization will only tell you why the case has failed, and the unit tests will tell you why it has failed and can locate specific problems. If the customer tests fails and all unit tests pass, the unit test case is missing. (Missing unit test)

Tests shocould help us understand the SUT

The test case is a good document that tells you what SUT has done. At the same time, it also allows you to directly debug test cases, perform one-step tracking, and learn how the entire system works.

Tests shocould reduce (and not introduce) Risk

1. The tests as safety net test case should be a security guarantee for modifying the Code, so that we can be bold in restructuring the old code without worrying about damages.
2. Do no harm test cases cannot affect the product. An important principle is not to modify SUT.

Tests shoshould be easy to run

1. Fully automation test is fully automated
2. Self-checking test can perform self-check. To put it bluntly, you do not need to manually check the result of case execution.
3. Repeatable test must be reproducible. Developers are encouraged to execute a test case every time they press the Save button (I like Ctrl + S ). The case must be reproducible and must be self-cleaning. Generally, the environment is cleaned up in teardown of test fixture.

Tests shoshould be easy to write and maintain

1. The primary principle of simple tests is to make the test cases as simple as possible to make them easier to maintain. Test only one condition at a time (verify one condition per test)
2. Expressive tests test cases must be clearly stated. For example, you can use creation mehods and custom assertion. A bit like BDD.
3. Separation of concerns test case should try to test a single, independent function, do not rely on too much. It is often necessary to participate in the design for testability of the product in the early stage ).

Tests shoshould require minimal maintenance as the system evolves around them

Test cases require minimal maintenance, so we need to write robust test cases (robust test ).

---------------

This chapter describes the purpose of the test. The sound of keeping the case simple, stable, and easy to maintain seems to be repeated constantly. Is it a bit annoying? Perhaps the author hopes that through this constant nagging, we can truly remember and accept, and finally realize and understand the benefits these things bring to us.