| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> |
| <!-- VERSION rmc:7.1.0 --> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
| <!-- START NON-TRANSLATABLE --> |
| <title>\xp\guidances\concepts\test_driven_development.xmi</title> |
| </head> |
| <!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. --> |
| <body> |
| Element Name: test_driven_development.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,1.620567348185129E-306 CRC: 2210588074 -->Test Driven Development<!-- END:presentationName,1.620567348185129E-306 --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,-yaD6WKGdrZ0n0yBSpwPr4g CRC: 3777617892 --><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,3.9254165491375454E-306.html" |
| guid="3.9254165491375454E-306">Test Driven Development Guidelines</a>. |
| </p><!-- END:mainDescription,-yaD6WKGdrZ0n0yBSpwPr4g --> |
| </body> |
| </html> |