<?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.4/uma.ecore"
    xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmi:id="-yaD6WKGdrZ0n0yBSpwPr4g"
    name="test_driven_development,1.620567348185129E-306" guid="-yaD6WKGdrZ0n0yBSpwPr4g"
    changeDate="2006-11-21T18:06:48.997-0500" version="1.0.0">
  <mainDescription>&lt;a id=&quot;XE_xp__test_driven_development&quot; name=&quot;XE_xp__test_driven_development&quot;>&lt;/a>&lt;a id=&quot;XE_test_driven_development__practice_of&quot; name=&quot;XE_test_driven_development__practice_of&quot;>&lt;/a>&lt;a id=&quot;XE_engineering_practices__test_driven_development&quot; name=&quot;XE_engineering_practices__test_driven_development&quot;>&lt;/a> &#xD;
&lt;h3>&#xD;
    Description&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Test-Driven Development is one of the core programming practices of XP. Many of us have learned over the years the&#xD;
    value of writing automated tests for our code. Many of us have also learned the difficulty of writing tests after code&#xD;
    is already in place. Test-Driven Development takes a different, extreme approach to ensure that we test all code, all&#xD;
    the time.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The practice of Test-Driven Development requires a change in how you program and in how you think. You won't write&#xD;
    tests as an afterthought. You won't be trying to see if the code you have written works. Instead, you will write tests&#xD;
    as part of the everyday, every minute way of building software. Instead of writing detailed design specifications on&#xD;
    paper, write the spec in code. Instead of first striving to perfectly design a system on paper, use tests to guide your&#xD;
    design. Instead of coding for hours at a stretch only to find that the planning went awry, use Test-Driven Development&#xD;
    to pace yourself, always assuring forward progress with the firm foundation of an ever-growing suite of running tests.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The steps:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Have an idea where you are going.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Write a test that specifies a tiny bit of functionality.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ensure that the test fails (you haven't built the functionality yet!).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Write only the code necessary to make the test pass.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Refactor the code, ensuring that it has the clear and simple design for the functionality built to date.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Repeat until you have the desired functionality.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The rules:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Test everything that can possibly break.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Tests come first.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        All tests run at 100% all the time.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Test-Driven Development is infectious! Developers swear by it. Developers do not seem to abandon it after giving it an&#xD;
    honest trial.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Benefits&#xD;
&lt;/h3>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Testable modules are decoupled from other complex classes, resulting in &lt;b>loosely coupled modules&lt;/b>. Loosely&#xD;
        coupled modules are a sign of good design.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Code is written so that &lt;b>modules are testable in isolation&lt;/b>. Code written without tests in mind is often&#xD;
        highly coupled, a big hint that you have a poor object-oriented design. If you have to write tests first, you'll&#xD;
        devise ways of minimizing dependencies in your system in order to write your tests.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The &lt;b>tests act as documentation,&lt;/b> providing concrete examples of how to use the module being tested.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The tests are the first client of your classes; they &lt;b>show how the developer intended the class to be used&lt;/b>.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The &lt;b>tests act as a safety net&lt;/b>. Notifying the programmer immediately when a side-effect defect is introduced&#xD;
        into the system.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Development is paced&lt;/b>. You can stop at anytime with the tests describing the progress so far. Each&#xD;
        programming session gives a sense of satisfaction with getting some of the code working.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Related Information&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    For more information, see &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../xp/guidances/guidelines/test_driven_development_tdd.html&quot; guid=&quot;3.9254165491375454E-306&quot;>Test Driven Development Guidelines&lt;/a>.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>