| <?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" xmi:id="-FaP3sC0JKNPzZHOkS-UW0A" |
| name="test_first_design,_s7YkUBD2EdyfbNOwzwtrjw" guid="-FaP3sC0JKNPzZHOkS-UW0A" |
| changeDate="2007-06-05T14:58:02.750-0700"> |
| <mainDescription><p>
 |
| Test-first design is the practice of writing&nbsp;developer tests and&nbsp;implementation code concurrently and at a
 |
| very fine level of granularity.
 |
| </p>
 |
| <p>
 |
| In test-first design, the developer first writes a small portion of a&nbsp;developer test, and then writes just
 |
| enough&nbsp;implementation code to make that&nbsp;developer test compile and execute. Then they write a little bit more
 |
| of the test and then add enough code to make that new bit compile and pass. This cycle can last somewhere between 30
 |
| seconds and five minutes. Rarely does it grow to ten minutes. In each cycle, the tests come first. Once a unit test is
 |
| done, the&nbsp;developer goes on to the next test until there are no more tests to be written for the implementation of
 |
| the work item currently under development.
 |
| </p>
 |
| <p>
 |
| The practice of test-first&nbsp;design changes how&nbsp;the developer&nbsp;thinks. Tests are not written as an
 |
| afterthought. Instead, developer tests are written as part of the everyday, every minute way of building software.
 |
| </p>
 |
| <p>
 |
| What are&nbsp;the advantages of test-first design?
 |
| </p>
 |
| <ol>
 |
| <li>
 |
| Assumptions in the design are analyzed before the implementation code is written. To write developer tests, an
 |
| examination must be made of the behavior of each piece of code to be written, correct and incorrect behaviors must
 |
| be defined. In&nbsp;a way, writing the tests before the code can be considered a version of detailed design.
 |
| </li>
 |
| <li>
 |
| Code units designed&nbsp;for testability up front are cleaner and more loosely coupled.
 |
| </li>
 |
| <li>
 |
| Errors&nbsp;are found earlier. Errors or gaps in the requirements and design are identified before coding begins
 |
| when it could be more tempting to move ahead based on assumptions.
 |
| </li>
 |
| <li>
 |
| A clearer&nbsp;collaboration strategy between the developer and others that might be responsible for the
 |
| requirements, architecture, and design is put in place.&nbsp;During the creation of the tests, there must be a
 |
| meeting of the minds as to what&nbsp;has been specified. After that, the implementation can carry on with
 |
| confidence that there is a shared vision of what the code should do.
 |
| </li>
 |
| <li>
 |
| There are unambiguous criteria for completion of the code. When the tests pass, the code is working as specified.
 |
| Non-functional quality dimensions can be dealt with separately, but there is a clear moment when the code behaves
 |
| correctly.
 |
| </li>
 |
| <li>
 |
| The technique drives the developer to work in smaller increments with faster quality feedback. At any time the
 |
| developer is just one test away from having error-free code.
 |
| </li>
 |
| <li>
 |
| There is a separation of concerns and effort between getting code working and improving the quality of the code
 |
| that already runs correctly. Separating out these two areas of concern provides focus and time management support
 |
| to a developer who in one pass over the implementation makes it pass the tests as simply as possible and then in a
 |
| subsequent pass, looks for areas to improve.
 |
| </li>
 |
| </ol></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |