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 :)
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.
> But I'm genuinely curious how most people classify the difference between api and library.
JMS is an API [1], [2].
ActiveMQ [3] is an implementation of the JMS API.
Commons BeanUtils [4] is a library. The library itself has an API (that's how we interact with the library).
There is a semantic difference between the "JMS API" and the "BeanUtils API".
The former is just an API. It's a standard. It has no implementation. Implementations are all expected to utilize the API.
The latter is a library, but we need to talk to the library - and we do that through its API. However, the API that BeanUtils exposes is not standardized. It's by and large local to BeanUtils.
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 :)