Nine, the test of artificial intervention is required to automatically detect the system is a major advantage of testing. It ensures that it is not because of personal negligence, and does not increase programmers' workload. In some cases, there will be quite temptations to make you want simple output to compare, such as file content or interface layout. The problem that people can see at a glance may require a considerable effort to write a test. But I have to remember that the cost of the test is not only written when writing it, and it also includes the work you need every time you execute. So let it make it as a fool as possible, the more you will execute it, and it will help you. Another benefit of writing testing for this more complex problem is that you can carefully let yourself think that you want to guarantee what guidelines are not violated, what need to test? Another case where I encountered is the process of testing, including a modal dialog that requires user input, and the entire process will stop until the user's input is received. Such tests are simply disaster in dailyBuilding. The reason for causing it is that the logic of the test is not separated from the interface operation.
Eight, the complex test configuration environment has been tried to measure a method, must have two global monomeric objects, and then set up 10 local variables. In each TestCase's setup and Teardown are the code for generating the test environment. The reason for this is to depends on global objects and variables between code inside the subject. This dependency explicit specification should be used through the interface.
Seven, the test code that has moved to the whole body changed a class input and output, you found that more than 20 test cases were broken. Worse, you find that each change will face the same problem. The coupling test reflects the coupling program structure, which requires a method of decoupling to make the range of variations from spread. Another reason for this problem is that the code test is implemented and not intended. In this way, when the internal behavior of the program changes, the test has to be changed. This situation is particularly prone to occur when adding tests to existing code.
Sixth, have you seen a test of a plus method for a test for code and non-functional tests? It includes various possible combinations and various borders. Or see a complex test process, fly off various data like popcorn, but you have to guess your intentions through the process of mixing the name. Test drive development is not a test, and it is not necessary to blame all the tests all over. Good testing should be clearly expressing your intentions you want to achieve, and ensure that the program is really in line with these intentions.
5. The huge TestCase testcase corresponds to a module in the program, generally a class. Over-intebrises TestCase indicates too much responsibility, it should be decomposed in the "Reconstruction" method to decompose it. Another situation is that this TestCase corresponds to the class to provide an overall service, while the operation of other objects is invoked. If only the outermost layer is tested, there are often many contents to be measured, and there is a need to consider the combination of each part. This is a need for interface explicitly defining this class and other partial delegation, and then isolates the two by virtual objects.
Fourth, the test of red light is a test representing a certain agreement in the system has been broken, so this problem must be amended in order to ensure the normal operation of the system. Sitting on a test is not because this test is not suitable for the current program structure (in fact, this is due to another error, writing code and writing test). Modify this test, or simply delete it. The loss of alert against the red light is equal to the loss of most benefits of testing drive development.
Third, the big span test provides the input of the outermost layer of the system, and then the final result of the magic output. As an acceptance test, it is appropriate, and the first test that is often written is to test the high level test. However, if there is only this test, it is not enough. There is a need to have more instructions for the test code for the mechanism of this result. One standard for judging the test span is that each test should be passed within a few hours (my limit is one day, and the different people may adapt to smaller particle size). If you need to struggle for a week after a test, TDD will not have much help from you. It should be tested through a high-level test as soon as possible, and the focus is concentrated to a lower level object. Second, the tested test of the clothes Some tens of thousands of lines of code are only 2, 3 TestCases, often made by certain "core" modules or complex algorithms. Or just the results of a new function of someone try Ide. Such use methods are not stained with the test drive development. Test cases are not a safety cable, but a means of design and implementation, like a scaffolding and an integral part.
I am very lucky. Basically, the mistakes mentioned earlier have been committed, and they will have a different mistakes will be made later. However, I feel that these mistakes are not as big as the biggest mistake:
First, there are many reasons for non-writing tests to refuse TDD: progress is too tight, how to write test; this way is too quirky, unacceptable; what you do is too special, not suitable for testing driving development; Some of the code can't write test at all ...
This fact is accepted "People will make mistakes" (whether in writing procedures, or when applying new development processes), and face these errors, they are found, they define them, check and clear feedback results. In the end, maybe you will find that the initial fear has been disappeared with a step in the smoke, and your steps have already expanded to the field that has not been involved.
