7.1 Unit testing with junit in drjava  (Page 2/2)

As shown on the screen shot, DrJava clearly indicates in red the test method that failed and the difference between the expected and actual values. It also highlights the line of code in the test method where the failure occured.

There is one exception to the syntax of assertEquals , and that is when the values being compared are doubles . This is because round-off errors in calculating floating point values means that it is almost always impossible to generate the same value from two different calculations, even if mathematically they are the same. For instance, compate 2.3*2.3 and 5.29 . Mathematically identical, but on a PC running Windows, Java calculates them to be different by approximately 0.00000000000000089 (or 8.9e-16 in Java syntax). Thus, if the expected and actual values are to be of type double , then a 4'th input parameter is required. This last parameter is a tolerance value, a plus-or-minus amount within which one considers the expected and actual values to be equal. For instance: assertEquals("Testing doubles: 5.29 vs. 2.3*2.3", 5.29, 2.3*2.3, 9e-16); should pass, but assertEquals("Testing doubles: 5.29 vs. 2.3*2.3", 5.29, 2.3*2.3, 8e-16); should fail. Note that the tolerance value should always be a positive value.

Asserttrue(...)

Another method provided by TestCase is void assertTrue(String failResponse, boolean result) . This is a simplified version of assertEquals(...) used when the result can be expressed as a boolean true or false. Note that any test using assertTrue can also be written as assertEquals(failResponse, result, true). For instance we could write another test method to test the myMethod2() method of MyClass . The test class now has two test methods and JUnit will run both ot them when we click on "Test Current Document." Here, the second test method passes as shown in green below. The first method still fails and its error messages are still shown. Clicking on the error message will highlight the line where the error occured. Correcting the code in myMethod1(...) would result in all the test methods being listed in green with no error messages.

Fail(...)

For more complex testing, TestCase provides the void fail(String failResponse) method. Calling this method will immediately cause the test method to fail and the failResponse string will be displayed. Since this method does not know the actual or expected results, the failResponse string should contain more detailed information about what exactly failed and how it failed. In the next screen shot is an example of using fail(...) where the test code was written such that it would fail:

Additional capabilities

Note that any test method can call other methods if needed . This is useful when the testing procedure is complex and needs to be broken down into smaller pieces. Do not name these helper methods starting with "test" or they will be run separately as test cases! Using helper methods is also useful when certain types of tests are performed only under certain conditions. assertEquals(...) , assertTrue(...) and fail(...) can be called from anywhere, but the DrJava will only highlight the line in the main test method that generated the error, i.e. the line that called the helper method. It will not highlight the line in the helper method where the actual call to assertEquals(...) , assertTrue(...) or fail(...) was made.

Sometimes in complex testing scenarios, there is a significant amount of initialization work required to set up the system to be tested. This is often the case when testing a system of interdependent objects where the entire system must be set up before any single object can be tested. If the initialization code is the same for all the tests being conducted, the method protected void setup() can be declared and be used to execute the necessary initializations. To insure "clean" test runs, JUnit/DrJava re-instantiates the test class before running each test method. The setup() method, if it exists, is called before any test method is executed. This means that the test class cannot utilize any internal field values that one test method modifies and another test method expects to use as modified.

Likewise, in the event that after a test is run that significant amounts of common "clean-up" code is required, one can declare the method protected void tearDown() . This method runs after each test method and is useful for insuring, for instance, that files and network connections are properly closed and thus keep them from interfering with other tests.

The help system in DrJava has more detailed information on testing with JUnit, including how to create a test suite of multiple tests.