| <?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.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.5.0" xmi:id="-mItcFA1WMTAyJvkqMrXuMQ" |
| name="new_guideline,_5s_DUJ03EdyQ3oTO93enUw" guid="-mItcFA1WMTAyJvkqMrXuMQ" changeDate="2008-10-14T10:03:34.273-0700" |
| version="7.2.0"> |
| <mainDescription><h3>
 |
| Introduction
 |
| </h3>
 |
| <p>
 |
| With Test Driven Development (TDD) you do detailed design in a just-in-time (JIT) manner via writing a single test
 |
| before writing just enough production code to fulfill that test. When you have new functionality to add to your system,
 |
| perform the following steps:
 |
| </p>
 |
| <ol>
 |
| <li>
 |
| <strong>Quickly add a developer test</strong>. You need just enough implementation code to fail.&nbsp; For example,
 |
| a new method about to be added to a class could be created that just throws a fatal exception.
 |
| </li>
 |
| <li>
 |
| <strong>Run your tests</strong>. You will typically run the complete test suite, although for sake of speed you may
 |
| decide to run only a subset. The goal is to ensure that the new test does in fact fail.
 |
| </li>
 |
| <li>
 |
| <strong>Update your production code</strong>. The goal is to add just enough functionality so that&nbsp;the code
 |
| passes the new test.&nbsp;
 |
| </li>
 |
| <li>
 |
| <strong>Run your test suite again</strong>. If the tests fail you need to update your functional code and retest.
 |
| Once the tests pass, start over.
 |
| </li>
 |
| </ol><br />
 |
| <p>
 |
| <img height="600" alt="Test First Design Flow" src="./resources/test_first_design.jpg" width="294" />
 |
| </p>
 |
| <h4>
 |
| Why TDD?
 |
| </h4>
 |
| <p>
 |
| A significant advantage of TDD is that it enables you to take small steps when writing software, which is not only
 |
| safer it is also far more productive than writing code in large steps. For example, assume you add some new functional
 |
| code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new
 |
| code. It is much easier to find, and then fix, those defects if you've written five new lines of code than fifty lines.
 |
| The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in
 |
| smaller and smaller steps.
 |
| </p>
 |
| <p>
 |
| There are other common testing strategies (listed here in order of effectiveness).
 |
| </p>
 |
| <ol>
 |
| <li>
 |
| <strong>Write several tests first</strong>. This is a variant of TDD where you write more than one test before
 |
| writing just enough production code to fulfill those tests. The advantage is that you don't need to build your
 |
| system as often, potentially saving time. It has the disadvantage that you will write more production code at once,
 |
| increasing the difficulty of finding the cause of new bugs.
 |
| </li>
 |
| <li>
 |
| <strong>Test after the fact</strong>. With this approach you write some production code then you write enough
 |
| testing code to validate it. This has the advantage that you're at least still validating the code but has the
 |
| disadvantage that you lose the design benefit inherent in writing the testing code first.
 |
| </li>
 |
| </ol>
 |
| <p>
 |
| An underlying assumption of TFD is that a unit-testing framework is available. Agile software developers often use the
 |
| xUnit family of open source tools, such as <a href="http://www.junit.org/"><strong><u><font
 |
| color="#0000ff">JUnit</font></u></strong></a> or <a href="http://www.vbunit.org/"><strong><u><font
 |
| color="#0000ff">VBUnit</font></u></strong></a>, although commercial tools are also viable options.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
