I'm using mapstruct in my project, and recently went to add some 'mutation analysis' using pitest.
The problem I have is that a mutant is created on some generated code, and I cannot fix my test to kill it since this is concerning null check generated by mapstruct, that are unreacheable.
ie, if I have the following mapper :
@Mapper
public abstract class MyMapper {
@Mapping(source= "someInnerObject.field", target="someField")
public abstract Bar toBar(Foo foo);
}
Mapstruck will generate something like this :
public class MyMapperImpl extends MyMapper {
@Override
public Bar toBar(Foo foo) {
if(foo == null) {
return null; // reacheable code, all is fine here.
}
Bar bar = new Bar();
bar.setSomeField(fooSomeField(foo))
return bar;
}
private String fooSomeField(Foo foo) {
if (foo == null) {
return null; // Unreacheable code, already tested in public method.
}
SomeInnerObject innerObject = foo.getSomeInnerObject()
if(innerObject == null) {
return null; // reacheable code, no problem here
}
String field = o.getField();
if(field == null) {
return null; // reacheable, no problem here.
}
return field;
}
}
As we can see, mapstruct generates a null check that is unreacheable, making it impossible to cover those line in test. The mutation analyser tries to return "" instead of null on the unreacheable line, and therefore, the mutant is never detected by my tests. This leads makes it impossible to get 100% code coverage and 100% mutation coverage.
I don't think excluding this generated code from the coverage or the mutation analysis would be a good choice, since the generated code reflect behavior that is coded as annotations in the mapper : So we would like to make sure these behaviors are correctly covered in tests.
Do someone here had the same problem, or any suggestion ?
I tried many different mapper config to get rid of the unreacheable line without success (unless I just disable all null checks, which would change my application logic).
The way MapStruct generates code doesn't allow us to skip the null check in the private method.
You can try raising an issue in the MapStruct project. However, I am not sure that it is worth spending time on skipping this null check. The JIT will in any case remove that check during runtime.
The topic about 100% code coverage and 100% mutation coverage is a topic for discussion that will lead to closing this question.