[jmsguy]

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.

[krzyk]

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)?

[ajanuary]

Depending on who you talk to, a unit isn't necessarily a single class.

[jmsguy]

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 :)