In my last post, I wrote about hints provided in NetBeans 7.4 beta that improve a developer’s ability to avoid nasty runtime issues with Java exception handling. In this post, I look at how two more hints provided by NetBeans 7.4 beta can be used to make unit tests more correct and more clear during unit test execution. These are the “Inconvertible parameters of Assert.assertEquals” and “Incorrect order of parameters of Assert.assertEquals” hints.
As far as I can tell from anecdotal evidence and from talking to other Java developers, JUnit remains the most widely used unit testing framework in the Java environment. Most of these JUnit users are intimately familiar with JUnit’s Assert class and its many overloaded assertEquals methods. NetBeans 7.4 beta now provides two hints to make it easier to use these assertEquals methods appropriately.
Although many of the Assert.assertEquals() methods have very specific data types for the “expected” and “actual” parameters to be asserted as equal, there is a version that accepts two Objects and this means two parameters of different types that cannot possibly be considered “equal” can still be passed to that method. There is no way for the compiler to prevent that, but NetBeans 7.4 beta includes the “Inconvertible parameters of Assert.assertEquals” hint to address that particular case. Without such a hint, one is more likely to not realize the error of his or her ways until he or she runs the JUnit test and sees the failed assertion.
One of the most common issues I’ve run into with JUnit (and one of the reasons I love Hamcrest‘s fluent API) is that I just cannot seem to remember with confidence which order the parameters to the assertEquals methods are. I have a 50/50 chance of being correct by guessing. Modern Java IDEs such as NetBeans help greatly when writing new JUnit code because their method completion features will indicate that the “expected” parameter is specified first and the “actual” parameter is specified second. More commonly, this is a problem when reading code rather than when writing it because there is no method completion helping me read the code. NetBeans 7.4 beta addresses this by highlighting the situation in which I have mixed up the parameters’ order via the “Incorrect order of parameters of Assert.assertEquals” hint. With that hint enabled (which it is by default), I can quickly recognize out-of-order parameters prior to runtime and even without method completion.
Both of the hints discussed above can be demonstrated in a very simple unit test class.
Portion of CalculatorTest.java
/**
* Test Calculator.sum(int ...).
*/
@Test
public void TestSumIntegers()
{
final Calculator calculator = new Calculator();
Assert.assertEquals(calculator.add(1, 2, 3, 4, 5), 15);
Assert.assertEquals("15", calculator.add(1, 2, 3, 4, 5));
}The code the above unit test method is testing is not important for this discussion. Rather, the focus is on the use of Assert.assertEquals in two cases. Both cases as shown above are incorrect and force demonstration of the two previously discussed NetBeans hints. The first attempt at asserting two objects are equal places the parameters in the wrong order. The “expected” value (hard-coded 15) should be listed first followed by the “actual” value calculated by the method under test. The second attempt at asserting two objects are equal will always fail because the types don’t match: the first parameter is a String and the second parameter is an integer. In both of these cases, the unit test code compiles without complaint. However, both assertions will ALWAYS fail when running the unit tests. In fact, these tests results may inadvertently be interpreted as problems with the code being tested until someone looks at the test failures in greater depth.
The next two screen snapshots demonstrate NetBeans 7.4 beta flagging both problematic unit testing assertion statements.
There is one caveat to note regarding the “Incorrect order of parameters of Assert.assertEquals” hint. It works well when the assertion statement is like the one shown in my example: a hard-coded expected value is provided as the “actual” value along with an obviously calculated value as the “expected” value. The next screen snapshot illustrates this point; only the statement I earlier showed is flagged by the hint and other ways of comparing actual to expected are not flagged, even when the order is incorrect.
The last shown screen snapshot demonstrates that the NetBeans hint is only able to detect an incorrect order of assertEquals parameters (should be expected before actual rather than actual before expected) in the case where those values are directly accessed in the statement (the actual calculation is performed for the first [expected] parameter and the expected hard-coded value is provided for the second [actual] parameter).
The two hints covered in this blog post make it easier to detect problems with the frequently used JUnit Assert.assertEquals methods that might not be detected until analysis of unit test run results without the hints. Although the two issues these hints warn developers about are typically fairly easy to detect and fix, detecting and fixing these problems is still more difficult and time-consuming than having the NetBeans IDE tell you they are wrong before you even run the test.
