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