Java Magazine, Nov/Dec 2016
ORACLE COM JAVAMAGAZINE NOVEMBER DECEMBER 2016 50 junit 5 For example take a look at line 73 of PrimitiveIntArray Subject java Pitest created a mutant that has the following description removed call to com google common truth PrimitiveIntArraySubject failWithRawMessage This message has been wrapped due to width constraints Ed What this tells you is that pitest commented out the line of code that called this method As the name suggests the purpose of failWithRaw Message is to throw a RuntimeException Google Truth is an assertion library so one of the core things that it does is throw an AssertionError when a condition is not met Lets take a look at the tests that cover this class The following test looks like it is intended to test this functionality @ Test public void isNotEqualTo_ FailSame try int same array 2 3 assertThat same isNotEqualTo same catch AssertionError e assertThat e hasMessage int 2 3 unexpectedly equal to 2 3 Can you spot the mistake It is a classic testing bug the test checks the content of the assertion message but if no exception is thrown the test passes Tests following this pattern normally include a call to fail Because the exception the Truth team expected is itself an AssertionError the pattern they followed in other tests is to throw an Error @ Test public void isNotEqualTo_ FailSame try int same array 2 3 assertThat same isNotEqualTo same throw new Error Expected to throw catch AssertionError e assertThat e hasMessage int 2 3 unexpectedly equal to 2 3 If this throw is added to the test the mutant is killed What else can pitest find There is a similar problem on line 121 of PrimitiveDoubleArraySubject java Again pitest has removed a call to failWithRawMessage However if you take a look at the test it does throw an Error when no exception is thrown So whats going on This is an equivalent mutant Lets examine this category of mutants a bit more Equivalent Mutants Equivalent mutants are the other problem identified by the academic research that I referred to in the introduction Sometimes if you make a change to some code you dont actually change the behavior at all The changed code is logically equivalent to the original code In such cases it is not possible to write a test that will fail for the mutant that doesnt also fail for the unmutated code Unfortunately it is impossible to automatically determine whether a surviving mutant is an equivalent mutant or just lacks an efective test case This situation requires a human to examine the code And that can take some time There is some research that suggests it takes about 15 minutes on average to determine if a mutation is equivalent
You must have JavaScript enabled to view digital editions.
