Test-driven development: Difference between revisions

Revision as of 11:40, 26 March 2024

Revision as of 16:31, 15 April 2024

Line 1:

{{short description|SoftwareCoding designtechnique usingof repetitively writing test casescode then production code}}

{{Software development process}}

'''Test-driven development''' ('''TDD''') is a way of writing [[software developmentsource processcode|code]] relyingthat oninvolves softwarewriting requirementsan being[[test converted toautomation|automated]] [[test case]]s beforethat softwarefails, isthen fullywriting developed,just andenough trackingcode allto softwaremake developmentthe bytest repeatedlypass, testingthen the[[refactoring]] softwareboth against allthe test cases.code Thisand isthe asproduction opposedcode, tothen softwarerepeating beingwith developedanother first andnew test cases created latercase.

Alternative approaches to writing automated tests is to write all of the production code before starting on the test code or to write all of the test code before starting on the production code. With TDD, both are written together.

Test-driven development is related to the test-first programming concepts of [[extreme programming]], begun in 1999,<ref name="Cworld92">{{cite web |url=http://www.computerworld.com/softwaretopics/software/appdev/story/0,10801,66192,00.html |title=Extreme Programming |author=Lee Copeland |date=December 2001 |publisher=Computerworld |access-date=January 11, 2011 |archive-url=https://web.archive.org/web/20110605060209/http://www.computerworld.com/s/article/66192/Extreme_Programming?taxonomyId=063 |archive-date=June 5, 2011 |url-status=dead }}</ref> but more recently has created more general interest in its own right.<ref name=Newkirk>Newkirk, JW and Vorontsov, AA. ''Test-Driven Development in Microsoft .NET'', Microsoft Press, 2004.</ref>

Test-driven developmentTDD is related to the test-first programming concepts of [[extreme programming]], begun in 1999,<ref name="Cworld92">{{cite web |url=http://www.computerworld.com/softwaretopics/software/appdev/story/0,10801,66192,00.html |title=Extreme Programming |author=Lee Copeland |date=December 2001 |publisher=Computerworld |access-date=January 11, 2011 |archive-url=https://web.archive.org/web/20110605060209/http://www.computerworld.com/s/article/66192/Extreme_Programming?taxonomyId=063 |archive-date=June 5, 2011 |url-status=dead }}</ref> but more recently has created more general interest in its own right.<ref name=Newkirk>Newkirk, JW and Vorontsov, AA. ''Test-Driven Development in Microsoft .NET'', Microsoft Press, 2004.</ref>

Programmers also apply the concept to improving and [[software bug|debugging]] [[legacy code]] developed with older techniques.<ref name=Feathers>Feathers, M. Working Effectively with Legacy Code, Prentice Hall, 2004</ref>

Line 23 ⟶ 25:

;1. Create a list of tests for the new feature

:The initial step in TDD, givenGiven a system & a desired change in behavior, is to list all the expected variants in the new behavior. “There’s the basic case & then what if this service times out & what if the key isn’t in the database yet &…” The developer can discover these specifications by asking about [[use case]]s and [[user story|user stories]]. A key benefit of test-driven development is that it makes the developer focus on requirements ''before'' writing code. This is in contrast with the usual practice, where unit tests are only written ''after'' code.

;2. Add one test from the list

:Write an automated test that passes if the variant in the new behavior is met.

;3. Run all tests. The new test ''should ''fail'' for expected reasons

:This shows that new code is actually needed for the desired feature. It validates that the [[test harness]] is working correctly. It rules out the possibility that the new test is flawed and will always pass.

;4. Write the simplest code that passes the new test

Line 40 ⟶ 42:

:** splitting methods into smaller pieces

:** re-arranging [[Inheritance (object-oriented programming)|inheritance hierarchies]]

;7. Add the next test on the list

:Repeat the process with each test on the list until all tests are implemented and passing.

;Repeat

:Repeat the process, starting at step 2, with each test on the list until all tests are implemented and passing.

:The cycle above is repeated for each new piece of functionality. Tests should be small and incremental, and commits made often. That way, if new code fails some tests, the programmer can simply [[undo]] or revert rather than [[debug]] excessively. When using [[Library (computing)|external libraries]], it is important not to write tests that are so small as to effectively test merely the library itself,<ref name=Newkirk /> unless there is some reason to believe that the library is buggy or not feature-rich enough to serve all the needs of the software under development.