Java Magazine, Nov/Dec 2016
ORACLE COM JAVAMAGAZINE NOVEMBER DECEMBER 2016 44 junit 5 Whats Wrong with Code Coverage The problem is illustrated by some of the legacy tests I found within the code Take a contrived class such as this class AClass private int count public void count int i if i 10 count public void reset count 0 public int currentCount return count I might find a test that looked like this @ Test public void testStuff AClass c new AClass c count 11 c count 9 This test gives 100 percent line and branch coverage but tests nothing because it contains no assertions The test executes the code but doesnt meaningfully test it The programmer who wrote this test either forgot to add assertions or wrote the test for the sole purpose of making a code coverage statistic go up Fortunately tests such as this are easy to find using static analysis tools I also found tests like this @ Test public void testStuff AClass c new AClass c count 11 assert c currentCount 1 The programmer has used the assert keyword instead of a JUnit assertion Unless the test is run with the ea flag set on the command line the test can never fail Again bad tests such as this can be found with simple static analysis rules Unfortunately these werent the tests that caused my team problems The more troubling cases looked like this @ Test public void shouldStartWithEmptyCount assertEquals 0 testee currentCount @ Test public void shouldCountIntegersAboveTen testee count 11 assertEquals 1 testee currentCount @ Test public void shouldNotCountIntegersBelowTen testee count 9 assertEquals 0 testee currentCount You cant rely on code coverage tools to tell you that code has been tested
You must have JavaScript enabled to view digital editions.
