Java Magazine, Nov/Dec 2016
ORACLE COM JAVAMAGAZINE NOVEMBER DECEMBER 2016 52 junit 5 Pitest has mutated a method call that is conditionally executed after comparing two arrays with the operator If the code does not throw an exception at this point it will move on and perform a deep comparison of the arrays If they are not equal the code throws exactly the same exception as if the had returned true So this is a mutation in code that exists solely for performance reasons Its purpose is to avoid performing a more expensive deep comparison A large number of equivalent mutants fall into this category the code is needed but relates to a concern that is not testable via unit tests The first question this raises is whether the behavior of this method should be the same when given the same array as it is when given two diferent arrays with the same contents My view is that it should not If I am using an assertion library and I tell it that I expect two arrays not to be equal and then I pass it the same array twice I would find it useful for the message to tell me this perhaps by adding in fact it is the same array to the end of the failure message But perhaps I am wrong Maybe the behavior is better the way it is If the behavior remains the same what can be done to make the equivalent mutation go away I dont like the isNotEqualTo method It has two responsibilities It is responsible for comparing arrays for equality and it is responsible for throwing exceptions when passed two equal arrays What happens if those two concerns are separated into diferent methods by doing something like this public void isNotEqualTo Object expectedArray double tolerance double actual getSubject try double expected double expectedArray if areEqual actual expected tolerance failWithRawMessage s unexpectedly equal to s getDisplaySubject Doubles asList expected catch ClassCastException ignored Unequal since they are of different types private boolean areEqual double actual double expected double tolerance if actual expected return true if expected length actual length return false return compareArrayContents actual expected tolerance Now the equivalent mutant goes away The mutant has prompted me to refactor the code into something cleaner What is more I can now also use the new areEqual method to remove duplicate logic elsewhere in this class thereby reducing the amount of code Unfortunately not all equivalent mutants can be removed by re expressing the code If I uncomment the section of the configuration that enables pitests stronger set of mutation operators and rerun the test Ill get a mutant in the new areEqual method
You must have JavaScript enabled to view digital editions.
