Section 33.4. Barriers to Testing

33.4. Barriers to Testing

The major problem in speeding up test execution is tangled application code. Business logic in the presentation layer and database access code in the domain layer objects can make it difficult to test business rules in isolation. Even if the logic associated with a business rule is defined in a single class, it may still be impossible to test that logic without needing many other objects to be available.

This issue is primarily one of modularity. A lack of modularity has a big impact on the ease of changing a system; the more dependencies between different parts of a system, the more difficult it is to change it, let alone isolate and fix bugs in those parts. Many systems also have a problem with redundancy (see the Note).

Note

Once a system grows complex and is difficult to change, pieces of code are much more likely to be duplicated rather than reused. To reuse existing code, it is often necessary to change it so that it is available in a useful form. That may simply mean extracting it into a new method, or it may require a change to the class structure of the application. Without tests, such refactoring changes are difficult to carry out without introducing new bugs [Fow99], [Ker04]. Even with a refactoring tool, some changes inevitably have to be done by hand, with a good chance of errors being made.

So as the complexity grows, the developers learn from bitter experience that it is better to not change the existing code. An alternative approach is to duplicate code, but that leads to redundancy and thus inconsistency [HT00]. It goes like this: We end up with two or more pieces of code that carry out some taskredundancybut when it needs to be changed, only one piece is alteredinconsistency.

We now look at adapting the application incrementally, so as to avoid unnecessary risk.