Allowing 'avoidCallsTo' to Suppress Specific Methods Instead of Entire Classes"

[Kevin222004]

Currently, in Pitest, when using the avoidCallsTo configuration option, it suppresses all calls to methods within a specified class. However, there are scenarios where it would be beneficial to have more control and be able to suppress specific methods instead of suppressing an entire class.

---

Overview

Consider a situation where a class contains multiple methods, but only one of them requires suppression of mutations. Currently, the only option is to suppress all calls to the class, even if the other methods do not require suppression. With the proposed enhancement, developers could specify the exact methods that should be excluded from mutation analysis while allowing other methods to be subjected to mutation testing.

---

Examples

As example in this issue https://github.com/checkstyle/checkstyle/pull/13127#issuecomment-1595864175 we are trying to suppress https://github.com/checkstyle/checkstyle/blob/461944ca99db34ee419bb0a9030952621aaf93e4/src/main/java/com/puppycrawl/tools/checkstyle/checks/coding/EqualsAvoidNullCheck.java#L615-L616 this method only in which return Collections.unmodifiableSet(children); is mutated as return children

Know to avoid this if I try to use avoidCallsTo it will only allow to suppress the whole class. which I don't want. hence If I try to <avoidCallsTo>java.util.Collections.unmodifiableSet</avoidCallsTo> it is not working <avoidCallsTo>java.util.Collections</avoidCallsTo> and this will suppress the whole class which is also not expected. Similar things happen while I am trying to suppress method in my class https://github.com/checkstyle/checkstyle/blob/461944ca99db34ee419bb0a9030952621aaf93e4/src/main/java/com/puppycrawl/tools/checkstyle/checks/coding/EqualsAvoidNullCheck.java#L615-L616 I have tried both method as I mentioned above

as of last solution we have to create an extra new class and wrap such kind of method and then exclude it. hence new class is totally useless as it is already available by JDK

[Kevin222004]

@hcoles Please give your opinion

[hcoles]

avoidCallsTo was added relatively early in pitest's history as way to avoid logging calls. It would make sense for it to take a glob as most other parameters do, but this may have some unintended consquences for existing users of the call.

An entry like

com.example.Foo

Would currently filter out all calls to methods on Foo. If the parameter was redefined to take a glob, the existing entry would match nothing.

Easiest solution might be to create a new parameter (or create a new filter as a feature that takes parameters).