| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-CGSI-WD83sE5swSmSDjAYA" name="adopt_tdd_practice,_8yG48JRqEdyrdaw_xGakyw" guid="-CGSI-WD83sE5swSmSDjAYA" authors="Jim Ruehlin" changeDate="2008-10-14T09:58:19.000-0700" version="7.2.0"> |
| <mainDescription><h3>
 |
| Getting Started&nbsp;
 |
| </h3>
 |
| <p>
 |
| If you have just installed the test driven development (TDD) practice, start by reviewing the <a
 |
| class="elementLinkWithType"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/developer_testing_FEBDAED6.html"
 |
| guid="_ADwlAJRtEdyrdaw_xGakyw">Concept: Developer Testing</a>. 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 <a
 |
| href="http://www.agiledata.org/essays/tdd.html" target="_blank">Introduction to TDD</a>.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| <strong>TDD Adoption scenario</strong>
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <ol>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| <li>
 |
| Have the team review the material in this practice.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| <li>
 |
| Select a critical system implementation element to start applying TDD on. Begin using new TDD tools and techniques
 |
| to develop and test the code.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| <li>
 |
| Begin to use TDD as described in the practice. Write tests before writing system code.
 |
| </li>
 |
| <li>
 |
| Evaluate your TDD adoption based on the objectives and metrics that you defined.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| </ol>
 |
| <h4>
 |
| <br />
 |
| Common pitfalls
 |
| </h4>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
