Getting Started

If you have just installed the test driven development (TDD) practice, start by reviewing the Concept: Developer Testing. These will introduce you to the basics of what you need to know about developer testing in the context of TDD. For more introductory information, read this Introduction to TDD.

If your organization has never done developer testing before, start your adoption by educating the members of the team. Use the resources below for educational and reference materials. Begin to track your performance immediately, because that will give you quick feedback on how rapidly the team is adopting TDD, even if it is a very low form of adoption at first.

Tools are critical for creating and managing unit tests. Educate the team on using new tools, and discover which practices and features of the tools will work best in your environment.

Specify modest, attainable goals when adopting TDD. For instance, instead of insisting that every code change must have a developer test starting now, it may be better to limit TDD practices to a single important implementation element. This will allow the team to come up to speed on tools and learn new development habits while minimizing the impact on the overall schedule. After the team has gained some comfort with the new way of doing things (usually a couple of weeks or a single iteration), your refined method for TDD can be applied to all new or changed code. Continue increasing the team's capabilities with TDD by introducing new tools, constraints, monitoring, or methods in modest, attainable increments. This also allows the team to experience success with new techniques, which usually leads to a team that embraces rather than resists change.

Like all process changes, adopting TDD requires that team members change behaviors and develop new habits, such as writing code only when a test already exists to validate it. Developers will need the education provided by the links on this page, and the methods described in this practice, to develop these new behaviors. They will also need to have their new behaviors enforced by the team as a whole, and by management, until constantly writing tests while writing code is a habit. TDD is no different from other areas of process adoption. The managing body (bosses or the team) need to put as much effort into creating new behaviors as the individual developers do.

TDD Adoption scenario

Here is one possible scenario for adopting the TDD practice. You will want to add, change, or remove steps to design an adoption roadmap more suitable to your environment. Hiring a consultant experienced in TDD will also speed your adoption of the practice and help avoid common pitfalls.

1. Educate the team on TDD. Use the presentations and articles referenced in this practice as a starting place. It would also be helpful for developers to attend a class on developer testing and TDD.
2. Have the team review the material in this practice.
3. Extend this practice to reflect any important constraints or requirements in your organization. For instance, indicate any extra information that may need to be described when checking in system or test code, link to any materials that describe internal tools that your team is required to use, or create a guideline describing how each test must be documented or structured to conform to corporate standards.
4. Identify and prepare to collect the information or metrics that will tell you how well you are adopting this practice. Make sure that the metrics are easy to collect. Highly accurate metrics that are difficult to collect are often abandoned, so provide no value. Coarser measurements that are easy to collect usually provide sufficient information, and it is more likely that they will continue to be collected.
5. Identify the initial, modest goals for your TDD adoption, such as "An average of 2 tests per method for implementation element X". The goal is to be successful at some incremental amount of adoption, not to adopt everything in a single event. Make success a regular habit.
6. Select a critical system implementation element to start applying TDD on. Begin using new TDD tools and techniques to develop and test the code.
7. Select a time frame to evaluate the adoption of new TDD techniques. It should be long enough to allow new habits to start to develop, but short enough that changes can be made relatively quickly. This will generally be sometime between a couple of weeks and a couple of months.
8. Begin to use TDD as described in the practice. Write tests before writing system code.
9. Evaluate your TDD adoption based on the objectives and metrics that you defined.
10. Make adjustments based on your evaluation. Eliminate tools or tool features that do not prove effective, and increase practices that are efficient and improve quality.
11. Determine the next step in adoption. Early on, this will be to write tests for more and more implementation elements until TDD is performed on all software for the system. Often, you will be able to achieve this after just a few evaluation cycles.
12. Continue to examine how your developer testing can be improved. Address problem areas in regular project review meetings. Monitor testing sites (such as the ones referenced on this page), and have individual team members read new articles and books about developer testing. They can report back to the group to generate insight and discussion about more improvements that can be incrementally applied to your TDD practice.
13. Continue to extend or modify this practice to reflect how your team is performing TDD, and what the next increment of adoption should be for your team.

Common pitfalls

TDD is a new way of thinking about testing. Failing to plan and manage how the team's behavior needs to change over time increases the chance of failing at TDD. Keep the team focused on TDD, and watch for the team falling back into old habits.

Individuals may opt for expedience and skip "small" or "insignificant" tests in an effort to meet deadlines. TDD's payoff is later in the development cycle, when the team is working with a high-quality baseline rather than fixing a mountain of bugs that have piled up. No change is too small to be tested.

Individuals may ignore implementation refactoring once the code runs successfully. Implementation refactoring keeps the code maintainable and reduces code decay, a phenomenon where the average number of errors created by a code fix increases over time. The team must refactor after the code runs successfully in order to maintain stable code that can be maintained and improved over the long term.