Work with duplication between unit and integration tests

Question

I have an algorithm implemented by a number of classes, all covered by unit test.

I would like to reorganize it, which will change the behavior of the two classes. When I change one class and its tests, all unit tests pass, although the algorithm becomes incorrect until there is refactoring.

This example shows that full coverage of unit tests is sometimes not enough, and I need “integration” tests for the entire algorithm in terms of I / O. Ideally, such tests should completely cover the behavior of my algorithm.

My question is: it seems that by adding such integration tests, I make unit tests unnecessary and redundant. I do not want to support duplicate test logic. Should I remove my unit tests or leave them as is, for example. to facilitate finding errors?

Answer 1

This is part of the problem with too fine tests and is closely related to the implementation.

Personally, I would write tests that focus on the behavior of the algorithm and will consider this “unit”. The fact that it is divided into several classes is a detail of the implementation, just as the destruction of the function of a public method in several smaller private methods is also a detail of the implementation. I would not write tests for private methods separately, they would be tested using tests of the functionality of the public method.

If some of these classes are generally useful and will be reused elsewhere, I would think of writing unit tests for them at this point, since they themselves will have a certain behavior.

This will lead to some duplication, but this is normal, because these classes now have an open support contract (and which is used by both components that use it), which can be determined by these tests.

Interestingly, see the definition of Unit in this article.