Overview

Software development process and methodology represent a controversial area. The number of influences that drive the decision for one process or another methodology are innumerable. We as developers often don't have the last word and, when the time for discussion is over, must get along with whatever has been decided on. This is no reason, though, not to develop test-first from then on. If you need arguments for why unit testing in general and test-first in particular are also very good ideas in non-XP projects, this chapter is for you. If you are already working in an environment where test-driven coding is accepted practice, you might want to skip ahead to the . This chapter describes the role of unit tests in a software engineering environment. It shows how and at what cost automated unit tests based on the test-first approach can be integrated into a documented software process, and to what extent they are already integrated in commercial software engineering processes, such as the Rational Unified Process (RUP) . Such considerations concern corporate managers, project managers, and developers dealing with such processes and interested in the systematic introduction of unit tests. Heavyweight and document-oriented processes are less flexible than agile processes , and XP belongs to the latter. Small project teams developing software for a single customer often regard such software engineering processes as outdated. However, the use of such processes is meaningful, for example, when developing a combined hardware/software system. Late availability of the target hardware demands for early definition and "freezing" of requirements in general and interfaces in particular. In addition, the discipline of such management-oriented processes is necessary to coordinate large distributed project teams, teams working on a new standard product, for example. And finally, there are areas where defined software engineering processes are formally required by the customer, such as development projects for government agencies.

Developing and introducing a different work method into a large development department usually means high investments. For this reason, a cost-benefit analysis should be conducted before decisions are made about the use of automated unit tests. The cost-benefit ratio depends largely on the structure of the process used. This chapter first introduces different process structures-sequential, incremental, and evolutionary structures-and then studies costs and benefits in relation to the respective structure. Finally, we will discuss the use of automated unit tests in popular commercial process models.