JUnit3.1.8 (Keep The Bar Green to Keep The Clean)
First, system structure diagram
Second, JUNIT test rumor
1. Each time I use only an object to a UT test (Unit-Test One Object At A Time) so that you can find problems as soon as possible without being confused by complex relationships between individual objects.
2, give the test method, a good name (Choose Meaningful Test Method Name) should be used as TestXxxyYYYYY (), such format to name your test method. The prefix test is the basis for the JUnit lookup test method. XXX should be the name you test, YYY should be the status you test. Of course, if you need a state, you need to test directly to Testxxxx ().
3, explicitly writing error Calls When using AssertTrue, Assertfalse, AssertNotnull, the possible error should be introduced to the corresponding method in the first parameter. This makes you quickly find out the cause of the error.
4, a UT test method should only test a situation in one method in one method, will only confuse your testing purposes.
5, test any possible abnormality (Test Anything That Could Possibly Fail)
6. Let your test help to improve your code (Let the test improve the code) test code is always our first user, so we not only let us help us find BUG, but also to help us improve our design It is a famous test drive development (Test-Driven Development, TDD).
7, so that more intuitive test abnormalities (make exception tests easy to read) try {controller.addHandler (request, handler); I fail ( "An exception should be raised if XXX");} catch (RuntimeException expected) {assertTrue (true If there is no error, it can be seen directly to see an abnormal condition.
8, the same package, different position (Same package, Separate Directories) testing code and the test code should be placed in different folders, it is recommended to use this directory src / java / code SRC / TEST / test code. You can use the same package structure in two codes, but put it in different directories.
9. Refactor, advanced topic, by testing optimization code.
10, (Don't Write Business Logic in Mock Objects)
11, (ONLY TEST What CAN POSSIBLY BREAK)
12, (Put Cactus Tests in Their Own Directories)
13, (Refactor Long Setups When Using Mock Objects)
14, (Refactor test setups and teardowns)
Third, the type of test
1, UT test
2, comprehensive test
3, function test
4, pressure test
5, acceptance test
Fourth, the stub test method (mainly used in coarse-grained test) 1. Define: The code used to replace a part of the functionality in the real system (do not confuse with the stub in EJB). When the components or environment necessary for the system test is more complicated, the test is used to replace the specific components when a specific result is generated. As shown in the figure: (Real System) (Test System) Instead of the actual sevlet using an HTML file. Just like testing the client in the Infogrid project.
2. Principle: Use a STUB code to imitate Web Server, Database, FileSystem ....
3, drawback:
1) If the simulated environment is too complicated, the Stub itself becomes very complicated, causing Stub itself to test.
2) After all, it is an simulation and does not completely replace the real environment.
5. Testing in isolation with Mock Obects test (mainly for Fine-grained)
1. Define Mock Object: Is an object to be used instead of the code, you can call the Mock Object method, he will return to you yourself set the result.
2, advantage
1), only test a separate object, when you mistake, don't have to judge which class error.
2), Mock Object, does not contain any business logic, and simply do not need to test. Sixth, in-container testing with cactus (http://jakarta.apache.ort/CACTUS/) did not look
