<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:PracticeDescription xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore"
    xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf"
    epf:version="1.5.0" xmi:id="-nV4dgKPmOiwZnl6nUoKqQw"
    name="new_practice,_FUDtMB4mEd2bS8fFOQ7WWA" guid="-nV4dgKPmOiwZnl6nUoKqQw" changeDate="2008-08-14T15:23:09.871-0700"
    version="7.5.0">
  <mainDescription>&lt;p>&#xD;
    Test driven development (TDD) is the practice of writing developer tests and implementation code concurrently&#xD;
    and at a very fine level of granularity.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In test driven design, the developer first writes a small test to validate a small change, runs the test to&#xD;
    ensure that it fails (a sanity check), and then writes just enough implementation code to make that developer test&#xD;
    run successfully. This cycle is short and it rarely goes beyond 10 minutes. In each cycle, the tests come first. Once a&#xD;
    test is done, the developer goes on to the next test until there are no more tests to be written for the&#xD;
    implementation of the work item currently under development.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img alt=&quot;file:///C:/Documents%20and%20Settings/Administrator/Desktop/tdd_flow.jpg&quot; src=&quot;./resources/tdd_flow.jpg&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The practice of test driven development changes how the developer thinks. Tests are not written as an&#xD;
    afterthought. Instead, developer tests are written as part of the everyday, every minute way of building software.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    What are the advantages of test driven design?&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        Assumptions in the design are analyzed before the implementation code is written. To write developer tests, an&#xD;
        examination must be made of the behavior of each piece of code to be written. Correct and incorrect behaviors must&#xD;
        be defined. In a way, writing the tests before the code can be considered a version of detailed design.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Code units designed for testability up front are cleaner and more loosely coupled.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Errors are found earlier. Errors or gaps in the requirements and design are identified before coding begins,&#xD;
        when it could be tempting to move ahead based on assumptions.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        A clearer collaboration strategy between the developer and others that might be responsible for the&#xD;
        requirements, architecture, and design is put in place. During the creation of the tests, there must be a&#xD;
        meeting of the minds as to what has been specified. After that, the implementation can carry on with&#xD;
        confidence that there is a shared vision of what the code should do.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        There are unambiguous criteria for completion of the code. When the tests conclude successfully, the code is working as specified.&#xD;
        Non-functional quality dimensions can be dealt with separately, but there is a clear moment when the code behaves&#xD;
        correctly.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The technique drives the developer to work in smaller increments with faster quality feedback. At any time, the&#xD;
        developer is just one test away from having error-free code.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        There is a separation of concerns and effort between getting code working and improving the quality of the code&#xD;
        that already runs correctly. Separating out these two areas of concern provides focus and time management support&#xD;
        to a developer. In one pass over the implementation, the developer makes it pass the tests as simply as possible, and then in a&#xD;
        subsequent pass, looks for areas to improve.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;p>&#xD;
    See &lt;a class=&quot;elementLink&quot; href=&quot;./../../../practice.tech.test_driven_development.base/guidances/supportingmaterials/using_tdd_in_context_2ADBB50B.html&quot; guid=&quot;_vLvAUGjFEd2PJ-nlV-86WA&quot;>Using TDD in context&lt;/a> for more information.&#xD;
&lt;/p></mainDescription>
  <additionalInfo>&lt;p>&#xD;
    If you are just getting started with TDD or developer testing in general, you will need to know why developer testing is a&#xD;
    good idea, and the basics of what makes good developer tests. A good starting place is this &lt;a href=&quot;http://itc.conversationsnetwork.org/shows/detail301.html&quot; target=&quot;_blank&quot;>Kent Beck presentation&lt;/a>. Kent Beck&#xD;
    is the creator of Extreme Programming, which is where TDD was originally defined.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Here are some useful links to expand your understanding of TDD. Make use of these as you learn to enact TDD. Some of&#xD;
    these links are also good resources for on-going support and information.&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        The &lt;a href=&quot;http://en.wikipedia.org/wiki/Test_driven_development&quot; target=&quot;_blank&quot;>TDD: Wikipedia&lt;/a> entry gives&#xD;
        an overview of TDD and links to other TDD resources.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;http://blog.james-carr.org/?p=44&quot; target=&quot;_blank&quot;>James Carr's TDD Anti-pattern Catalogue&lt;/a> lists some&#xD;
        things to avoid when adopting TDD.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The &lt;a href=&quot;http://blog.james-carr.org/?p=44&quot; target=&quot;_blank&quot;>TDD Mailing List&lt;/a> is a discussion forum for TDD&#xD;
        questions and issues.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;http://www.testdriven.com/&quot; target=&quot;_blank&quot;>Testdriven.com&lt;/a> is a developer testing site with a wealth&#xD;
        of information, news, and partner links about developer testing.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Read the TDD whitepaper &lt;a href=&quot;http://www.agiledata.org/essays/tdd.html&quot; target=&quot;_blank&quot;>Introduction to TDD.&lt;/a>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Once you are familiar with the basics of TDD, select various tasks to view more detail about what needs to be&#xD;
    done to perform the task. If you will be creating a capability pattern or delivery process that includes TDD, see &lt;a class=&quot;elementLink&quot; href=&quot;./../../../practice.tech.test_driven_development.base/guidances/supportingmaterials/using_tdd_in_context_2ADBB50B.html&quot; guid=&quot;_vLvAUGjFEd2PJ-nlV-86WA&quot;>Using TDD in context&lt;/a>. This shows one example of how TDD can be used in conjunction&#xD;
    with other activities and capability patterns to create a pattern for developing software. This is only one possible&#xD;
    example: there are many was to use TDD with other development practices.&#xD;
&lt;/p></additionalInfo>
  <problem>&lt;p>&#xD;
    The test driven development practice reduces time to market by reducing the amount of time needed to integrate and&#xD;
    stabilize builds. It improves productivity by finding and fixing errors close to the time that they are introduced. And it&#xD;
    increases the overall quality of the software by guaranteeing that all new code has been tested, and all existing code has&#xD;
    been regression tested, prior to check-in.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Developers use TDD to create the &lt;a class=&quot;elementLink&quot; href=&quot;./../../../core.tech.common.extend_supp/workproducts/implementation_AFFEFC46.html&quot; guid=&quot;_JqYbgJ01EdyQ3oTO93enUw&quot;>Implementation&lt;/a> and the &lt;a class=&quot;elementLink&quot; href=&quot;./../../../core.tech.common.extend_supp/workproducts/developer_test_6A91CE05.html&quot; guid=&quot;_kh9FcJ02EdyQ3oTO93enUw&quot;>Developer Test&lt;/a>s.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    See the &lt;a class=&quot;elementLink&quot; href=&quot;./../../../practice.tech.test_driven_development.base/guidances/roadmaps/adopt_tdd_practice_7D642D12.html&quot; guid=&quot;_8yG48JRqEdyrdaw_xGakyw&quot;>How to Adopt the Test Driven Development Practice&lt;/a> for information on navigating&#xD;
    the TDD Practice.&#xD;
&lt;/p></problem>
  <background>&lt;p>&#xD;
    TDD was originally part of Kent Beck's Extreme Programming process. It's now also used in many other Agile and&#xD;
    non-Agile contexts.&#xD;
&lt;/p></background>
</org.eclipse.epf.uma:PracticeDescription>