There are a number of ways in which one can test that the proper result is produced. The simplest method is to compare a single output value to an expected value. For instance, suppose you are testing a method that returns a result. One can compare the actual returned value to the value one expects for the given inputs. There are two methods supplied by the junit.framework.TestCase class, which is the superclass of the test class generated by DrJava. The first is void assertEquals(String failResponse, Object actual, Object expected). The actual input parameter is the actual result of the method under test. The expected parameter is the expected result. failResponse is a String that JUnit/DrJava will display if the actual value does not "equal" the expected value. The assertEquals(...) method is overridden such that actual and expected values can be either Objects or primitives. assertEquals(...) uses the equals(...) method of Object to makes it determination. For primitives, the usual == is used. For instance, we could write the test case below. If the actual value does not equal the expected value, assertEquals throws a exception that is caught by the JUnit framework and an error message will result. To test the code, first compile all the code then select the test class. Right-click the test class and select "Test Current Document "or click on "Tools/Test Current Document." The following result will be displayed, given the test code we wrote to purposely fail:
Using assertEquals(...) in a test case
As shown on the screen shot, DrJava clearly indicates in red the test method that failed and the diference 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-of 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 diferent 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.
- 2235 reads
