It was recently suggested to me that the code quality of unit tests is irrelevant as the tests are not part of what is delivered. I take this view to be based on an incorrect understanding of the purpose of unit tests.

As I've previously discussed unit tests are not primarily about short term bug reduction. The value of unit tests is delivered over the lifetime of the project. This inevitably means that the tests will need to be modified over time to reflect the new desired behaviour of the application and to accommodate changes to its structure. Hence the maintainability of the unit tests will be a significant factor in the maintainability of the system over time.

If we do not consider the maintainability of unit tests then over time the effort required to alter tests to accommodate changes will become a serious concern. Tests will tend to be fragile, where any change will break large numbers of tests. This imposes a serious maintainability burden that can outweigh the benefits supplied by the unit tests. Inevitably if this tendency is not arrested there can be only two possible outcomes:

• The overhead of maintaining the tests will destroy the ability of the team to make progress and the project will stall.
• Unit testing will be abandoned in order to permit development to occur

Neither of these scenarios are desirable but I've lived through them happening. This is the kind of thing that gives unit testing a bad name and makes some developers consider it unnecessary or counter productive.

To prevent these situations unit test code must be treated in the same way as production code. It should be refactored to remove duplication and pay down Technical Debt. This activity does not directly deliver functionality to end users. Rather it is the necessary cost of adopting the practice of Test Driven Development.