Section 33.9. Summary

33.9. Summary

We have strongly advocated that Fit tests express the business rule tests as clearly as possible. This may seem difficult to do because it is so easy to get caught up in the way things are, or will be, implemented, instead of the essence of what's needed from a business perspective. It may also seem strange because it seems like rework, with the application having to change to aid testability.

We have seen how we can, step by step, eliminate dependencies that get in the way of testing. In the previous chapter, we started by rejecting the idea of testing through the UI explicitly in the Fit tables and showed how the fixtures could act as adapters to do that job.

We then looked at how to eliminate or reduce dependencies between the domain objects and the presentation and the data source layers and other domain objects. The adaptation of the application to enable testing needs to be done carefully, so as to minimize the risk of lowering quality. As tests are introduced from the outer level, the UI, they can support refactorings that enable still more test access.

There may be complex internal logic that is dependent only vaguely on the business logic and so will not be tested with the Fit tables. In that case, the process of adaptation needs to continue deeper into the application, with the support of programmer tests, such as in JUnit.

The changes we need to make to enable direct testing have huge benefits in other respects. Making a system testable for business-oriented tests and for programmer tests leads to strong modularity and a reduction in redundancy. It is not uncommon to add functionality to well-structured software by generalizing and shrinking the code.

Experience has shown that driving the development of the code with tests, at the business and programmer levels, can lead to high-quality systems that continue to be refreshed as they change. Doing a little refactoring all the time, as a part of the design process, can mean that development goes more quickly rather than more slowly. The reason is that much less effort is spent in bug fixing and rework, and it is much easier to enhance good-quality code.

Questions & Answers

Q1:	What if the application is a real mess?
A1:	Rather than refactoring step by step what you have, it may be better to start with a fresh application that's developed test first and to slowly bring relevant pieces of code across step by step. This is especially good when required enhancements to the system break important assumptions about the current architecture. However, you may find it difficult to make a convincing case for this, as it appears as if it's going backwards, even though the result will be better and you will get there sooner.
Q2:	What about domain objects that don't have a UI and that simply encode business rules?
A2:	The principle is still the same, in that modularity may need to be improved. However, there may be good reason to add UI for a newly isolated object that manages a business rule. A provided UI makes available to users a special business rule calculator. For example, they would be able to explore the consequences of various given values on the calculated values without having to commit data changes to find out.