| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:PracticeDescription 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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="-nV4dgKPmOiwZnl6nUoKqQw" |
| name="new_practice,_FUDtMB4mEd2bS8fFOQ7WWA" guid="-nV4dgKPmOiwZnl6nUoKqQw" changeDate="2008-08-14T15:23:09.871-0700" |
| version="7.5.0"> |
| <mainDescription><p>
 |
| Test driven development (TDD) is the practice of writing developer tests and implementation code concurrently
 |
| and at a very fine level of granularity.
 |
| </p>
 |
| <p>
 |
| In test driven design, the developer first writes a small test to validate a small change, runs the test to
 |
| ensure that it fails (a sanity check), and then writes just enough implementation code to make that developer test
 |
| run successfully. This cycle is short and it rarely goes beyond 10 minutes. In each cycle, the tests come first. Once a
 |
| test is done, the 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>
 |
| <img alt="file:///C:/Documents%20and%20Settings/Administrator/Desktop/tdd_flow.jpg" src="./resources/tdd_flow.jpg" />
 |
| </p>
 |
| <p>
 |
| The practice of test driven development changes how the developer 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 the advantages of test driven 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 a way, writing the tests before the code can be considered a version of detailed design.
 |
| </li>
 |
| <li>
 |
| Code units designed for testability up front are cleaner and more loosely coupled.
 |
| </li>
 |
| <li>
 |
| Errors are found earlier. Errors or gaps in the requirements and design are identified before coding begins,
 |
| when it could be tempting to move ahead based on assumptions.
 |
| </li>
 |
| <li>
 |
| A clearer collaboration strategy between the developer and others that might be responsible for the
 |
| requirements, architecture, and design is put in place. During the creation of the tests, there must be a
 |
| meeting of the minds as to what 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 conclude successfully, 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. In one pass over the implementation, the developer makes it pass the tests as simply as possible, and then in a
 |
| subsequent pass, looks for areas to improve.
 |
| </li>
 |
| </ol>
 |
| <p>
 |
| See <a class="elementLink" href="./../../../practice.tech.test_driven_development.base/guidances/supportingmaterials/using_tdd_in_context_2ADBB50B.html" guid="_vLvAUGjFEd2PJ-nlV-86WA">Using TDD in context</a> for more information.
 |
| </p></mainDescription> |
| <additionalInfo><p>
 |
| If you are just getting started with TDD or developer testing in general, you will need to know why developer testing is a
 |
| good idea, and the basics of what makes good developer tests. A good starting place is this <a href="http://itc.conversationsnetwork.org/shows/detail301.html" target="_blank">Kent Beck presentation</a>. Kent Beck
 |
| is the creator of Extreme Programming, which is where TDD was originally defined.
 |
| </p>
 |
| <p>
 |
| Here are some useful links to expand your understanding of TDD. Make use of these as you learn to enact TDD. Some of
 |
| these links are also good resources for on-going support and information.
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| The <a href="http://en.wikipedia.org/wiki/Test_driven_development" target="_blank">TDD: Wikipedia</a> entry gives
 |
| an overview of TDD and links to other TDD resources.
 |
| </li>
 |
| <li>
 |
| <a href="http://blog.james-carr.org/?p=44" target="_blank">James Carr's TDD Anti-pattern Catalogue</a> lists some
 |
| things to avoid when adopting TDD.
 |
| </li>
 |
| <li>
 |
| The <a href="http://blog.james-carr.org/?p=44" target="_blank">TDD Mailing List</a> is a discussion forum for TDD
 |
| questions and issues.
 |
| </li>
 |
| <li>
 |
| <a href="http://www.testdriven.com/" target="_blank">Testdriven.com</a> is a developer testing site with a wealth
 |
| of information, news, and partner links about developer testing.
 |
| </li>
 |
| <li>
 |
| Read the TDD whitepaper <a href="http://www.agiledata.org/essays/tdd.html" target="_blank">Introduction to TDD.</a>
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Once you are familiar with the basics of TDD, select various tasks to view more detail about what needs to be
 |
| done to perform the task. If you will be creating a capability pattern or delivery process that includes TDD, see <a class="elementLink" href="./../../../practice.tech.test_driven_development.base/guidances/supportingmaterials/using_tdd_in_context_2ADBB50B.html" guid="_vLvAUGjFEd2PJ-nlV-86WA">Using TDD in context</a>. This shows one example of how TDD can be used in conjunction
 |
| with other activities and capability patterns to create a pattern for developing software. This is only one possible
 |
| example: there are many was to use TDD with other development practices.
 |
| </p></additionalInfo> |
| <problem><p>
 |
| The test driven development practice reduces time to market by reducing the amount of time needed to integrate and
 |
| stabilize builds. It improves productivity by finding and fixing errors close to the time that they are introduced. And it
 |
| increases the overall quality of the software by guaranteeing that all new code has been tested, and all existing code has
 |
| been regression tested, prior to check-in.
 |
| </p>
 |
| <p>
 |
| Developers use TDD to create the <a class="elementLink" href="./../../../core.tech.common.extend_supp/workproducts/implementation_AFFEFC46.html" guid="_JqYbgJ01EdyQ3oTO93enUw">Implementation</a> and the <a class="elementLink" href="./../../../core.tech.common.extend_supp/workproducts/developer_test_6A91CE05.html" guid="_kh9FcJ02EdyQ3oTO93enUw">Developer Test</a>s.
 |
| </p>
 |
| <p>
 |
| See the <a class="elementLink" href="./../../../practice.tech.test_driven_development.base/guidances/roadmaps/adopt_tdd_practice_7D642D12.html" guid="_8yG48JRqEdyrdaw_xGakyw">How to Adopt the Test Driven Development Practice</a> for information on navigating
 |
| the TDD Practice.
 |
| </p></problem> |
| <background><p>
 |
| TDD was originally part of Kent Beck's Extreme Programming process. It's now also used in many other Agile and
 |
| non-Agile contexts.
 |
| </p></background> |
| </org.eclipse.epf.uma:PracticeDescription> |
