Section 18.6. Tests and Change

18.6. Tests and Change

Inevitably, the Fit tests for a system will change as the business changes and as the needs of the business are better understood in relation to that system. Tests that are difficult to change will become a handicap, either slowing down development or becoming out of date and ignored.

Tests are difficult to change when they're not well organized or are difficult to understand. But the most common problem occurs when many similar changes need to be made to a large set of tests. It is very easy to miss one or two places where a change was required, leading to inconsistency between tests. We'd hope that such inconsistencies will be picked up when the tests are run against the revised system, but this is not guaranteed.

18.6.1. Redundancy

The need for many similar changes stems from redundancy, some of which results from unnecessary detail in tests. So one of the aims of table design is to reduce the redundancy in tests. However, we cannot eliminate it.

Redundancy arises when the same thing is said more than once. Such repetition makes for longer tests and more tests to change when the business rules change. But some redundancy is inevitable because we need to include the name of a client, for example, in many tests. Luckily, the approaches to managing change of Fit tables are mostly consistent with our communication aims.^[4]

^[4] They differ in that eliminating too much redundancy will make tests more difficult to read.

18.6.2. Smell: Duplication

If you find yourself copying several tables of one test to create a new test, you may be creating unnecessary duplication and thus redundancy. If you find that you're having to compare long tests with one another to determine the differences, those tests may contain redundancies.

Various specific smells were given earlier, along with approaches to avoiding such duplication:

• Unnecessary detail (Section 18.2.7)

• Tangled tables (Section 18.2.8)

• Long tables (Section 18.2.10)

• Laborious action-based tests for calculation (Section 18.3.2)

• Rambling workflow (Section 18.3.6)

• Similar Setup (Section 18.3.7)

• Convoluted Setup (Section 18.3.8)

• Many columns (Sections 18.4.1 and 18.5.1)

• Lots of rows (Sections 18.4.3 and 18.5.2)

18.6.3. Smell: Tests Changing Often

If the tests are changing more quickly than the needs of the system, a problem may exist. Maybe the tests include details about things that are still being decided premature commitment. Or maybe the tests include too much irrelevant detail.

As we saw in Section 18.2.7, the biggest smell arises when Fit tests for general business rules are expressed as operations through the user interface. Of all the components of an application, the user interface is the one most likely to change.

In addition, if Fit tests are written early on in development, it will be unclear how the user interface will work. So rather than making premature commitments to something that's not essential to the business rule, leave that detail out. As we show programmers in Chapter 32, the fixtures for Fit tests for the tables in Chapter 14 may test the system under test through the user interface, without any need for that to be mentioned in the Fit tests themselves.

If we're testing too close to the GUI, we need to think about the actions that we want to carry out in a more abstract way. So rather than thinking about filling in a form, through several operations on the user interface, think about the fundamentals of the action. For example, the tests in Part II make no commitment to the user interface operations that may be carried out on the system.