so if i read this correctly "This filter will not work for tests that utilise classes via interfaces, reflection or other methods where the dependencies between classes cannot be determined from the byte code."
if you are using interfaces to inject and mock things, it cannot test your code?
this sounds really cool, but most of the stuff we do is down with interfaces...
No - pitest has no problems with the use of interfaces, reflection etc.
The sentence you quoted relates to an optional feature that allows the tests that will be run against a mutated class to be limited to those within a certain "distance" (i.e number of method calls) from it.
The feature is little used, but is useful in some very specific circumstances.
Even if you do enable it, it would only cause a problem if the class under test was only referred to within the test by some interface that it implemented (which would be very unusual). The fact that the classes dependencies were declared as interfaces would cause no problems.
Unit tests should have exactly one system under test. That has to be a class, not an interface.
You may mock dependencies that may/may not be interfaces. This is safer than using concrete dependencies whose behaviors may change once the fuzzer does its thing.
The behaviors of the classes that implement the mocked dependencies have nothing to do with the system under test.
So if you're writing unit tests that exactly one unit, you should be good to go.
Regarding one system under test, is there a java library (with maven preferably) that would check that unit test is performing tests on single class and all the rests are mocked (e.g. with mockito, or with custom anonymous classes)?
Actually this is a really good talking point that's often the start of many interesting "discussions":
Namely, what happens when you're done with the test-code-repeat cycle for a system under test and you want to make it more architecturally sound / OO / etc.
You typically might end up doing a refactor in which you extract classes from the original system under test and colocating common functionality into new class(es).
In this way you still have the same coverage as before... But you're actually testing multiple classes as a unit.
Some folks would argue you need to split the tests out. Otherwise would say "the coverage is there, what's the point?".
Unless I need to do something, I'm not going to do it.
In playing with pitest, it looks like the refactorings might introduce some fuzzing that needs to be considered in the original (and refactored) SUT depending on how much conditional logic you're moving around.
Arghh. There goes my evening. Will be playing with this after work now :)
if you are using interfaces to inject and mock things, it cannot test your code?
this sounds really cool, but most of the stuff we do is down with interfaces...