Chapter 15: Loose Ends and Opportunities

Overview

The last chapter of any book bears a great deal of responsibility, because various reader groups meet again in this chapter. All those who read from cover to cover wish an overall summary including suggestions for further approach. Those who read selected chapters would like to learn here what they didn't have time to read in detail. And all those who read only the last chapter want to see the core statement of this book presented on half a page. Let's begin with an executive summary.

Testing is—still—a neglected area in the software development discipline, and many developers like to close their eyes to it. The truth is that the programming level is ideal for the use of automated unit tests, not only to reduce the number of bugs, but also to facilitate the developer's work. Contrary to what some may think, test cases do not slow down the programming process; they accelerate it, because they catch errors early and they facilitate refactoring of an existing program, or even make it possible in the first place. This opens up a chance for continual extension of your application, without falling into the feared "maintenance trap."

The test-first approach is a continuation of the test automation idea. This approach requires the creation of test cases before creating the actual application code. This means that tests assume a new, additional task: they considerably influence the design of an application and are thus the control instrument of an evolutionary design. In contrast to the widely used approach that tries to design as many details of a system as possible in advance, the test-first approach puts us in a position to further develop the fine design of a system in micro-iterations in a few minutes.

However, working by the test-first approach is by no means easy, and it requires each developer to rethink, especially in the beginning. Before you feel comfortable with this new way of programming, you have to learn basic steps and get over a few psychological hurdles. This book dealt with these initial problems and a large number of advanced issues and testing techniques. Where necessary, we represented the theoretical basics, and the reader's attention was drawn to questions that cannot be generally answered. Chapter 14 discussed the question of how test-first development can be integrated into the software processes commonly used today, probing each single technique with regard to its contribution to the whole—the development of software.

Despite all techniques and special cases discussed in this book, a large part is based on simplified assumptions:

• With the test-first approach, we begin from zero; that is, there is no software we can build on or adapt.

• At the beginning of a project, the development team masters at least the basics of test-first programming.

• The team is the master over the entire code; there are no interfaces to other projects.

In fact, only very few projects meet all of these conditions. For this reason, the author puts the following ideas and approaches up for discussion.