This book has been found for a long time and has never been read. There are few good books about software testing.CodeThe reconstruction and model of books is even more difficult. Although I have read the previous chapters, I feel that this book is indeed comprehensive and provides professional terms for many tests, I believe that after reading and absorbing this book, I will have more experiences and gains.
The first chapter is the overview of the book, Jump directly to the second chapter to start my notes. Test smell, the bad taste of the test. The Code smell is the same as the Code smell we usually talk about. The difference is that test smell analyzes the bad taste in the test process from the test perspective. The bad taste of the test is divided into three types:
- Code smells
- Behavior smells
- Project smells
These three bad tastes are not independent. The root cause of Project smells may be code smells and behavior smells.
Project smells
Project smells may occur in the following situations:
- Production bugs products have a high number of bugs
- Continuous building of daily integration build always fails, or it takes a lot of time to solve a compilation problem.
- Too many problematic test cases of buggy tests will affect the project efficiency.
- Devolopers not writing tests developers do not write test cases, resulting in more production bugs
- Lost tests Test Case insufficient
Behaivor smells
It is easy to find that you do not need to monitor it, because the test case compilation fails, or the test case fails, usually when behavior smell appears:
- Fragile tests is a test case that is prone to failures. A slight change may cause failure of the test case. This usually occurs in the "Recording playback" test case. This case is not only unstable, but also difficult to maintain. Because the automatically generated code is usually difficult to understand and maintain.
- The main causes of fragile tests are:
- This is the most common interface sensitivity. For example, if the development modifies the function interface and a button on the interface is adjusted, the case may fail to be executed.
- Behaivor sensiti.pdf the behavior of the code under test has changed. Of course, the test case will fail. (If the test fails, the test case is faulty)
- Data sensiti.pdfProgramIf the data in the database changes, the case may fail.
- The Context Sensitivity environment changes, causing the case to fail. For example, time changes, hardware devices, and system environments.
Erratic tests unstable test cases, sometimes successful, sometimes failed:
- Interacting tests is commonly known as interacting. The previous cases affect the subsequent cases. For example, when shared fixture is used, the status of shared fixture is modified in the previous case, resulting in failure in all subsequent cases.
- Multiple test runners in test run wars use the same shared Fixture for execution at the same time. This is also the case where a failure occurs under special circumstances. This bug is usually fixed at the end of the day.
- Unrepeatable tests cannot ensure that the same result is returned for each execution. Sometimes manual intervention is required.
Too frequent debugging of frequent debugging indicates that automated unit tests are not enough, or too many functions are tested at a time in unit tests.
Fully automated tests uses agile TDD developers to execute test cases every few minutes, provided that the test cases must be automated without manual intervention. If manual intervention is required, few people are willing to perform those test cases on a regular basis.
The execution of slow Tests cases must be fast. If the execution is slow, the results cannot be fed back to the development quickly. Of course, it will also make development unwilling to execute those slow and unstable cases. The solution is to use shared fixture. Code smells
The bad taste of the Code is basically the same as Martin Fowler's refactoring. By looking at the code, we can find many bad tastes:
- Obscure tests: If your test case is confusing, you have no idea what you are testing. Later, the maintainer modified this test case and probably wrote an error, resulting in another buggy tests.
- The conditional test logic Test Case Logic should be as single as possible, and only one branch should be tested. If there are too many logics in a test case, it will be confusing.
- The data used in the hard-coded test data test, using hard encoding, will make people unable to understand the data and the data has a SUT connection.
- Test code duplication reduces repeated code and increases the reusability of test code. A common method is to use test utility methods.
- Test logic in production is difficult to add some testing logic to the product code. It is never guaranteed that the code used for testing will not be executed in the product.
This chapter briefly describes test smell. In the second part of this book, we will give a more detailed introduction to test smell.