TDD Injection in legacy code

In a typical agile team, the team practicing TDD would write the test first, plug the business logic, make the test to pass and refactor the code (RED-GREEN-REFACTOR). This luxury may not be available for teams (legacy teams) who are new to agile methodology, and have a huge code base developed without TDD. This article explains some of the techniques that could help introducing TDD into legacy development teams.

TDD Injection in legacy systems
--------------------------------

1. First step is to, identify the code smells that you would like to attack. You can do this by running any of the freely available code smell/quality identification tool (Checkstyle, PMD,JCosmo, etc)

Once you have the list ready, prioritize the list for developers to refactor. For example, "reducing the lengthy methods" could be of priority than the "replacing the magic numbers with static code".

According to me, not all the code smells could be tackled by the junior developers (2-4 years of experience) alone. Some of the code smells need extensive object oriented programming and design skills. For example, replacing "inheritance by delegation", needs a careful thought. In such cases, the senior members of the team Or developers with good OOAD/P knowledge needs to be involved.

2. Next step is to, consider each of these high priority code smells within each iteration. Allocate time to fix them and in parallel, write the unit tests for those parts of the refactored code. Writing the Unit tests at this point of time and automating them ensures that, the refactored code has not broken the behavior of the system. I would like to call this as "TDD injection" technique.

The reason for "TDD Injection" technique is to not only introduce TDD in the middle of development, but specifically refactoring the legacy code.

3. Some teams specifically allocate”Cleanup iteration" just before each milestone release. This is really not a good way to do agile development, but if the project planning is poor Or in a dysfunctional team, the developers might rush delivering the code to customer without TDD. In such situations, one can reserve a day or two “or” may be an entire iteration (2 weeks, say) for clean up activities.

=== "Something is better than nothing".