JUnit Test Suggestions The following is a good summary of JUnit practices, information comes from some compare authoritative JUnit books and online information. The collection here is as follows: 1, each time only one object is performed (Unit-Test One Object At A Time). This will make you discovered problems as soon as possible, not confused by complex relationships between individual objects.
2, give the test method, a good name (Choose Meaningful Test Method Names). It should be used as TestXxxyyyYY (), such formats 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 only have a state, you need to test directly to Testxxxx ().
3. Explicitly write the cause of EXPLAIN THE FAILURE REASON IN Assert Calls. When using AssertTrue, AssertFalse, AssertNotnull, an AssertNull method, a possible error should be described in the first parameter into the corresponding method. This way you can quickly find the reason for the error.
4, a UT test method should only test a situation (One Unit Test Equals One TestMethod). Multiple tests in a method will only confuse your testing purposes.
5. Test any possible mistake (Test Anything That Could Possibly Fail). Your test code is not to prove that you are right, but to prove that you are not wrong. Therefore, the scope of the test is comprehensive, such as boundary value, normal value, and error value; the problem that may occur on the code is fully predicted.
6, let your test help to improve your code (Let The Test Improve The Code). The test code will always be the first user of our code, so not only let him help us find BUG, but also to help our design, it is a famous test drive development (Test-Driven Development, TDD).
7, the same package, different positions (Same Package, Separate Director). The test code and the test-tested code should be placed in a different folder, which is recommended to use this directory src / java / code SRC / TEST / test code. This allows two code to use the same package structure, but put it in different directories. 8. About Setup and Teardowna) Do not initialize FixTure with TestCase, and use the setup () and Teardown () method. b) The code in Setup and Teardown should not be related to the test method, but should be globally related. Such as: Database links to be used with test methods, etc. c) When inheriting a test class, remember to call the parent class's setup () and teardown () methods. 9. Do not involve the business logic in Mock Object (Don't Write Business Logic In Mock Objects).
10, only testing the possibility of errors (ONLY TEST What CAN POSSIBLY BREAK). Such as: a function of frequent changes in a class. For classes that only contain Getter / setter, if it is generated by IDE (such as Eclipse), it can be unpredictable; if it is manually written, then it is best to test it.
