Introducing Unit Tests to the Development Team

We all know that a tutorial is suitable only to a limited extent to convey applicable knowledge, and even less to change people's behavior. An organization or a project manager determined to introduce test-driven development faces the question of how the introduction of unit testing into the work process of the development team will actually work. The smartest approach depends strongly on the general development approach of an organization. In this respect, we distinguish between the craftsmanship approach and the organizational approach.

The Craftsmanship Approach

In his tutorial entitled Software Craftsmanship, Pete McBreen [01] propagates the transition from software engineering to software development as a craft. In traditional craftsmanship, the abilities and reputation of the individual "master" play a decisive role in winning contracts. Quality and durability of a product are in the center, while training new craftsmen functions by the proven principle of apprentice, journeyman, and master. Extreme Programming and the other agile processes (see , ) can be viewed as typical software development methods by the craftsmanship approach. In the case of the craftsmanship development approach, a development team of manageable size will include an experienced developer, a master or journeyman, who will train the other team members by supporting them in their attempt at walking in a test-first environment and ensuring on the basis of his or her authority that all developers will correctly apply unit tests. If the team additionally uses coding in pairs, then the developers will mutually support each other in learning and continuous app of unit tests. The most important goal is to get a self-regulation mechanism going: short iterations→find slipped-through errors in tests →adapt and improve the testing practice.

A technique that allows coordination of such a craftsmanship approach across project borders is the so-called communities of practice [Cohen01]. Here, the master programmers form a community that meets regularly to exchange experiences and problems. This makes the realization of the test-first approach in various teams more uniform and more efficient, because a master programmer can obtain support from his or her peers in solving problems.

The Organizational Approach

In many larger development organizations, however, you won't find exclusively motivated teams, instructed in new technologies by a charismatic master programmer. In these cases, hierarchical management structures and formalized processes normally control the events. These rigid structures mostly have a negative impact on the team's commitment and willingness to learn. Such a case requires an organizational approach to introduce the test-first development method to ensure meaningful use of the technique. Such an approach is more expensive and clearly more unpleasant than the craftsmanship approach. But sometimes it is the only way to get both the management and the developers onboard. An organizational flow to introduce unit tests could look as follows:

Feasibility study, including cost-benefit analysis. The current development process should be used to determine whether and how unit tests can be integrated into the process before a decision in favor of introducing unit tests is made. If an integration is basically possible, then costs and benefits of unit tests should be compared, similarly to our evaluation in . In this respect, costs also include expenditures for steps following the process introduction.
Management decision and support. Based on the study in step 1, the manager in charge of the development organization (e.g., the head of the development department) decides on the introduction of unit tests. This manager will select a project for the introduction of unit tests, including a separate budget and manager for the project. The next steps will be taken within the scope of this project.
Adaptation of the development process. The implementation of the unit tests will be built into the existing process description. Changes concern the description of activities, integration of new intermediate products (e.g., test cases, test results), modified role description, and modified tool environment.
Implementation of pilot projects. Next, the changed process should be checked for its practical suitability, before it becomes the new standard. This means that experiences with the changed approach should be collected from a representative set of projects. The members of the pilot projects have to be trained in theory and practice. Following a general introduction, one promising method is coaching by an experienced test-first expert. Regular reviews are necessary to bring the quality of the created test suites to the required level.
Within a closed frame of a pilot project, we recommend the craftsmanship approach described earlier, even if the formal steps described are necessary on an organizational level.
Adaptation of the process based on the results. The process documentation is revised based on the experiences gained from the pilot projects. The resulting software process is reviewed and approved. This means that the unit tests have become an official part of the development process.
Rollout of unit tests within the organization. This is the step where the remaining developers of the organization participate in training programs about the test-first and unit testing issues. From now on, each new project will use unit tests. The important thing is that each project has at least one staff member who has already gained practical experience and is able to act as coach for the project team.

Of course, the six-step plan introduced above can also be used for other process improvements [Kaltio00]. The important thing is, here too, that there is only one change per cycle, because major changes in one shot will most likely fail or not be permanent. In any event, the introduction of unit tests in large organizations should be active and take place within a separate project. Otherwise, the test-first idea might land where many good ideas have been stranded before: in aging file cabinets and remote archives.