5

It happens that there are sometimes lines of code or methods that can't produce mutants that are going to be killed by any relevant test. (For instance I may be using a null pattern object, and some of the implemented methods are not relevant in prod, so any implementation (even throwing) would be correct).

It would be nice to be able to tell pit to avoid them (so that the mutation coverage is more relevant), but I couldn't find a way to do it in the documentation.

Is there a way to do it?

gturri
  • 13,807
  • 9
  • 40
  • 57

1 Answers1

7

PIT currently has five mechanisms by which code can be filtered out.

  1. By class, using the excludedClasses parameter
  2. By method, using excludedMethods
  3. Using a custom mutation filter
  4. By adding an annotation named Generated, CoverageIgnore, or DoNotMutate with at least class level retention. (N.B javax.annotation.Generated has only source retention and will not work)
  5. The arcmutate base extensions allow mutation to be filtered using code comments or external text files

For your use case it sounds like options 1, 4 or 5 would fit.

Option 2 only allows for a method to be filtered in all classes (this is most commonly used to prevent mutations in toString or hashcode methods).

Option 3 is a little involved, but would allow you to (for example) to filter out methods with a certain annotation.

An aside.

I don't I follow your example of the null object pattern.

A null object needs to implement all methods of an interface and it is expected that they will be called. If they were to throw this would break the pattern.

In the most common version of the pattern the methods would be empty, so there would be nothing to mutate apart from return values.

This behaviour would be worth describing with tests. If your null object fails to return whatever values are considered neutral this would cause a problem.

henry
  • 5,923
  • 29
  • 46
  • Thanks for the answer. For my null object example, I must admit I'm in practice in a particular case. My interface has the methods `hasValue` and `getValue`. My null object returns `false` for `hasValue` and `null` for `getValue`, but the rest of my codebase doesn't care about the `null` since it will never call this method because of the `false`. (yes I could still unit test it, but I'm more into small integration tests) – gturri Dec 18 '15 at 22:29
  • @henry have you got an example of how to use the excludedMethods? The documentation speaks of a glob, but I'm not sure how to use it. – Friso Mar 22 '16 at 13:58
  • > Generated, CoverageIgnore, or DoNotMutate what is the complete package names and where to download these annotations jar file – Raja Nagendra Kumar Mar 27 '23 at 18:25
  • @RajaNagendraKumar Any annotations matching those names will work, regardless of the package (so long as they have runtime retention). Or there are some pre-packaged here -> https://search.maven.org/search?q=a:pitest-annotations – henry Mar 28 '23 at 07:06