JUnit is not very difficult, but it is not easy to write a good TestCase. A bad TestCase is often a waste of time and can't play actual role. Instead, a good TestCase can not only pointed out the problems in the code, but also as a more accurate document as a code, and it is also very important in the process of continuous integration. Several points you need to pay attention to when you write TestCase:
- The independence of the test: Only one object is tested once, it is convenient to position the wrong position. This has 2 dense: a TestCase, only test an object; a TestMethod, only one method in this object.
- give a test method a suitable name.
- Reasons for failed in the Assert function, such as: Asserttrue ("... Should Be true", ...), easy to find out. In this example, if it is not possible to pass Asserttrue, then the given message will be displayed. Each Assert function in JUnit has the first parameter is a function prototype of the message when an error is wrong.
- Test all places that may cause fail, such as: Frequent modified functions 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.
- The code in Setup and Teardown should not be related to the test method, but should be globally related. For example, the code in SETUP and TEARDOWN should be the code required by A and B.
- Test code organization: the same package, different directories. In this way, the test code can access the protected variable / method of the test class, which is convenient for test code. Placing in different directories, it is convenient for the management of the test code and the package and release of the code. An example is as follows:
SRC <= Source Code Root Catalog | --- COM | --- MOD1 | --- Class1junit <= Test Code Root Catalog | --- COM | --- Mod1 | --- Class1
