Which unit tests to remove

Unit tests in Java usually test classes via setting dummy state and executing methods. On many projects the number of units tests increases, and they are rarely removed.

Unfortunately too many unit tests can have negative consequences, because they make changes in production code more difficult.

In theory unit tests should prevent changes that introduce bugs and defect regressions.

In practice, I see that a lot of tests that check API calls more than the (business) functionality. This has the following negative repercussion:

• tests pass even if you utterly brake production code (as long as the right sequence of API calls is maintained),
• Making changes to production code is difficult because unit tests are hard-wired to the existing API structure, a change in production code leads to a cascade of changes in test code.

Sometimes it would be beneficial to throw some unit tests out. I have gathered some advice on which unit tests are good candidates for removal (mostly from James Coplien and from my experience). They are as follows:

• tests that always succeed (never fail for more than ~ 1 year),
• test that don’t change when functionality of the system changes,
• tautological tests (e.g. setting something and checking if it’s there),
• tests in which it’s not possible to pinpoint what business functionality is invalidated when they fail,
• unit tests that can be changed to assertions,
• tests that duplicate what integrations tests already do.