8 Maintainability

 

This chapter covers

  • Root causes of failing tests
  • Common avoidable changes to test code
  • Improving the maintainability of tests that aren’t currently failing

Tests can enable us to develop faster, unless they make us go slower due to all the changes needed. If we can avoid changing existing tests when we change production code, we can start to hope that our tests are helping rather than hurting our bottom line. In this chapter, we’ll focus on the maintainability of tests.

Unmaintainable tests can ruin project schedules and are often set aside when the project is put on a more aggressive schedule. Developers will simply stop maintaining and fixing tests that take too long to change or that need to change often as the result of very minor production code changes.

If maintainability is a measure of how often we are forced to change tests, we’d like to minimize the number of times that happens. This forces us to ask these questions if we ever want to get down to the root causes:

  • When do we notice that a test fails and therefore might require a change?
  • Why do tests fail?
  • Which test failures force us to change the test?
  • When do we choose to change a test even if we are not forced to?

This chapter presents a series of practices related to maintainability that you can use when doing test reviews.

8.1 Changes forced by failing tests

8.1.1 The test is not relevant or conflicts with another test

8.1.2 Changes in the production code’s API

8.1.3 Changes in other tests

8.2 Refactoring to increase maintainability

8.2.1 Avoid testing private or protected methods

8.2.2 Keep tests DRY

8.2.3 Avoid setup methods

8.2.4 Use parameterized tests to remove duplication

Summary