Applying Test-Driven Development (TDD) to brownfield development is relatively easy if the project was properly tested. Unfortunately, that is not often the case. Applying TDD is still the right thing to do, but it is more difficult. There is not always time to create a robust test base, but not doing so introduces quality and schedule risk.

When asked to formalize a prototype, the first step is take is to design black-box test cases with curated inputs (i.e. not complex real-world data) to determine what the program does. What the prototype does will often be different from what it is supposed to do because it has not been properly tested. If possible, correct the prototype before formalizing it so that formal program correctness can more-easily be proven.

Code-level unit tests should be developed after the black-box tests are in place. The unit testing process differs based on whether or not the formal program is written in the same language as the prototype.

Same Language: For each requirement...

1. Create unit tests for the code that fulfills the requirement.
2. Do not formalize the code yet, just test it.
3. Allow interface and implementation nuances discovered through testing to inform requirements discovery.

Different language: While there are still requirements to test...

1. Design code that fulfills the requirement and write an interface for access to it.
2. Create unit tests for that interface that will exercise the requirement; they fail now.
3. Implement the design that fulfills the requirement.
4. Enhance or correct the code and unit tests until all pass.
5. Introduce the new code into the formal program.
6. Run the black-box tests on the formal program expecting more of them to pass.
7. Allow differences in the test results to guide requirements discovery.

The processes described above represent the most favorable conditions. When asked to quickly correct or enhance a large, poorly tested program, use this same process, but focus testing on the requirements you are modifying and ignore the rest. It’s an imperfect solution to an problematic situation, but it’s better than winging it.

After testing is in place, focus on corrections or enhancements. The rest of the process is the same as greenfield TDD: Prove that the program does not do when it should do before modifying it.