| <?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><a id="XE_xp__test_driven_development" name="XE_xp__test_driven_development"></a><a id="XE_test_driven_development__practice_of" name="XE_test_driven_development__practice_of"></a><a id="XE_engineering_practices__test_driven_development" name="XE_engineering_practices__test_driven_development"></a> 
 |
| <h3>
 |
| Description
 |
| </h3>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| The steps:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Have an idea where you are going.
 |
| </li>
 |
| <li>
 |
| Write a test that specifies a tiny bit of functionality.
 |
| </li>
 |
| <li>
 |
| Ensure that the test fails (you haven't built the functionality yet!).
 |
| </li>
 |
| <li>
 |
| Write only the code necessary to make the test pass.
 |
| </li>
 |
| <li>
 |
| Refactor the code, ensuring that it has the clear and simple design for the functionality built to date.
 |
| </li>
 |
| <li>
 |
| Repeat until you have the desired functionality.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| The rules:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Test everything that can possibly break.
 |
| </li>
 |
| <li>
 |
| Tests come first.
 |
| </li>
 |
| <li>
 |
| All tests run at 100% all the time.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Test-Driven Development is infectious! Developers swear by it. Developers do not seem to abandon it after giving it an
 |
| honest trial.
 |
| </p>
 |
| <h3>
 |
| Benefits
 |
| </h3>
 |
| <ul>
 |
| <li>
 |
| Testable modules are decoupled from other complex classes, resulting in <b>loosely coupled modules</b>. Loosely
 |
| coupled modules are a sign of good design.
 |
| </li>
 |
| <li>
 |
| Code is written so that <b>modules are testable in isolation</b>. 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.
 |
| </li>
 |
| <li>
 |
| The <b>tests act as documentation,</b> providing concrete examples of how to use the module being tested.
 |
| </li>
 |
| <li>
 |
| The tests are the first client of your classes; they <b>show how the developer intended the class to be used</b>.
 |
| </li>
 |
| <li>
 |
| The <b>tests act as a safety net</b>. Notifying the programmer immediately when a side-effect defect is introduced
 |
| into the system.
 |
| </li>
 |
| <li>
 |
| <b>Development is paced</b>. 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.
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Related Information
 |
| </h3>
 |
| <p>
 |
| For more information, see <a class="elementLinkWithUserText" href="./../../../xp/guidances/guidelines/test_driven_development_tdd.html" guid="3.9254165491375454E-306">Test Driven Development Guidelines</a>.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
