| <?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>openup&#92;guidances&#92;guidelines&#92;&#92;test_first_design.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_first_design.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_0Y6kUMlgEdmt3adZL5Dmdw CRC: 3904523993 -->Test-first Design<!-- END:presentationName,_0Y6kUMlgEdmt3adZL5Dmdw --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_0Y6kUMlgEdmt3adZL5Dmdw CRC: 3271981756 -->This guideline explains how to apply test-first design.<!-- END:briefDescription,_0Y6kUMlgEdmt3adZL5Dmdw --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,_Hg5UUMPbEdmbOvqy4O0adg CRC: 1812519036 --><h3> |
| Introduction |
| </h3> |
| <p> |
| With Test-First Design (TFD) 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. 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 the code |
| passes the new test. |
| </li> |
| <li> |
| <strong>Run your test suite again</strong>. If they 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 TFD? |
| </h4> |
| <p> |
| A significant advantage of TFD 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 other common testing strategies (listed here in order of effectiveness). |
| </p> |
| <ol> |
| <li> |
| <strong>Write several tests first</strong>. This is a variant of TFD 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><br /> |
| <h3> |
| Good Things to Know |
| </h3> |
| <p> |
| 1. 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>JUnit</strong></a> or <a href="http://www.vbunit.org/"><strong>VBUnit</strong></a>, although commercial tools are also viable options. |
| </p> |
| <p> |
| 2. Test-Driven Design (TDD) = TFD + <a class="elementLink" href="./../../../openup/guidances/concepts/refactoring_1B63BA3B.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a> |
| </p> |
| <p> |
| 3. TFD/TDD is commonly used with object-oriented business code, although this approach can be taken with procedural |
| code, user-interface code, and database code. |
| </p><!-- END:mainDescription,_Hg5UUMPbEdmbOvqy4O0adg --> |
| </body> |
| </html> |