<?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>&lt;h3>&#xD;
    Getting Started&amp;nbsp;&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    If you have just installed the test driven development (TDD) practice, start by reviewing the &lt;a&#xD;
    class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../core.tech.common.extend_supp/guidances/concepts/developer_testing_FEBDAED6.html&quot;&#xD;
    guid=&quot;_ADwlAJRtEdyrdaw_xGakyw&quot;>Concept: Developer Testing&lt;/a>. These will introduce you to the basics of what you need&#xD;
    to know about developer testing in the context of TDD. For more introductory information, read this &lt;a&#xD;
    href=&quot;http://www.agiledata.org/essays/tdd.html&quot; target=&quot;_blank&quot;>Introduction to TDD&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If your organization has never done developer testing before, start your adoption by educating the members of the team.&#xD;
    Use the resources below for educational and reference materials. Begin to track your performance immediately, because&#xD;
    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&#xD;
    first.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Tools are critical for creating and managing unit tests. Educate the team on using new tools, and discover which&#xD;
    practices and features of the tools will work best in your environment.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Specify modest, attainable goals when adopting TDD. For instance, instead of insisting that every code change must have&#xD;
    a developer test starting now, it may be better to limit TDD practices to a single important implementation element.&#xD;
    This will allow the team to come up to speed on tools and learn new development habits while minimizing the impact on&#xD;
    the overall schedule. After the team has gained some comfort with the new way of doing things (usually a couple of&#xD;
    weeks or a single iteration), your refined method for TDD can be applied to all new or changed code. Continue&#xD;
    increasing the team's capabilities with TDD by introducing new tools, constraints, monitoring, or methods in modest,&#xD;
    attainable increments. This also allows the team to experience success with new techniques, which usually leads to a&#xD;
    team that embraces rather than resists change.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Like all process changes, adopting TDD requires that team members change behaviors and develop new habits, such as&#xD;
    writing code only when a test already exists to validate it. Developers will need the education provided by the links&#xD;
    on this page, and the methods described in this practice, to develop these new behaviors. They will also need to have&#xD;
    their new behaviors enforced by the team as a whole, and by management, until constantly writing tests while writing&#xD;
    code is a habit. TDD is no different from other areas of process adoption. The managing body (bosses or the team) need&#xD;
    to put as much effort into creating new behaviors as the individual developers do.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;strong>TDD Adoption scenario&lt;/strong>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Here is one possible scenario for adopting the TDD practice. You will want to add, change, or remove steps to design an&#xD;
    adoption roadmap more suitable to your environment. Hiring a consultant experienced in TDD will also speed your&#xD;
    adoption of the practice and help avoid common pitfalls.&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        Educate the team on TDD. Use the presentations and articles referenced in this practice as a starting place. It&#xD;
        would also be helpful for developers to attend a class on developer testing and TDD.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Have the team review the material in this practice.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Extend this practice to reflect any important constraints or requirements in your organization. For instance,&#xD;
        indicate any extra information that may need to be described when checking in system or test code, link to any&#xD;
        materials that describe internal tools that your team is required to use, or create a guideline describing how each&#xD;
        test must be documented or structured to conform to corporate standards.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Identify and prepare to collect the information or metrics that will tell you how well you are adopting this&#xD;
        practice. Make sure that the metrics are easy to collect. Highly accurate metrics that are difficult to collect are&#xD;
        often abandoned, so provide no value. Coarser measurements that are easy to collect usually provide sufficient&#xD;
        information, and it is more likely that they will continue to be collected.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Identify the initial, modest goals for your TDD adoption, such as &quot;An average of 2 tests per method for&#xD;
        implementation element X&quot;. The goal is to be successful at some incremental amount of adoption, not to adopt&#xD;
        everything in a single event. Make success a regular habit.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Select a critical system implementation element to start applying TDD on. Begin using new TDD tools and techniques&#xD;
        to develop and test the code.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Select a time frame to evaluate the adoption of new TDD techniques. It should be long enough to allow new habits to&#xD;
        start to develop, but short enough that changes can be made relatively quickly. This will generally be sometime&#xD;
        between a couple of weeks and a couple of months.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Begin to use TDD as described in the practice. Write tests before writing system code.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Evaluate your TDD adoption based on the objectives and metrics that you defined.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Make adjustments based on your evaluation. Eliminate tools or tool features that do not prove effective, and&#xD;
        increase practices that are efficient and improve quality.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Determine the next step in adoption. Early on, this will be to write tests for more and more implementation&#xD;
        elements until TDD is performed on all software for the system. Often, you will be able to achieve this after just&#xD;
        a few evaluation cycles.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Continue to examine how your developer testing can be improved. Address problem areas in regular project review&#xD;
        meetings. Monitor testing sites (such as the ones referenced on this page), and have individual team members read&#xD;
        new articles and books about developer testing. They can report back to the group to generate insight and&#xD;
        discussion about more improvements that can be incrementally applied to your TDD practice.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Continue to extend or modify this practice to reflect how your team is performing TDD, and what the next increment&#xD;
        of adoption should be for your team.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;h4>&#xD;
    &lt;br />&#xD;
    Common pitfalls&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    TDD is a new way of thinking about testing. Failing to plan and manage how the team's behavior needs to change over&#xD;
    time increases the chance of failing at TDD. Keep the team focused on TDD, and watch for the team falling back into old&#xD;
    habits.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Individuals may opt for expedience and skip &quot;small&quot; or &quot;insignificant&quot; tests in an effort to meet deadlines. TDD's&#xD;
    payoff is later in the development cycle, when the team is working with a high-quality baseline rather than fixing a&#xD;
    mountain of bugs that have piled up. No change is too small to be tested.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Individuals may ignore implementation refactoring once the code runs successfully. Implementation refactoring keeps the&#xD;
    code maintainable and reduces code decay, a phenomenon where the average number of errors created by a code fix&#xD;
    increases over time. The team must refactor after the code runs successfully in order to maintain stable code that can&#xD;
    be maintained and improved over the long term.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
