Difference between revisions of "Test-driven development"
Jump to navigation
Jump to search
(→Sources: += InfoQ » Scott Ambler » The Life and Times of TDD) |
(Sources += JavaScript Scene » Eric Elliott » 5 Questions Every Unit Test Must Answer) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
[[TDD]]: | |||
*is an approach that combines {{p|test-first development}} (TFD) and {{p|refactor code}}; | |||
*writes a test before it writes the code—the test in effect does double duty in that it both specifies and validates that piece of code; | |||
*can be used to specify detailed requirements on a just-in-time (JIT) basis throughout construction—writing the acceptance test ''is'' the documentation; a.k.a. {{p|acceptance test-driven development}} or {{p|behavior-driven development}}; | |||
*makes small changes to a product that do not change its semantics—in other words, {{p|refactor code}} is a clean-up activity that makes something better but does not add or subtract functionality; | |||
==Sources== | ==Sources== | ||
{{WebSourceListItem | {{WebSourceListItem | ||
| Line 5: | Line 10: | ||
|person=Scott Ambler | |person=Scott Ambler | ||
|title=The Life and Times of TDD | |title=The Life and Times of TDD | ||
}} | |||
{{WebSourceListItem | |||
|url=https://medium.com/javascript-scene/what-every-unit-test-needs-f6cd34d9836d | |||
|site=JavaScript Scene | |||
|person=Eric Elliott | |||
|title=5 Questions Every Unit Test Must Answer | |||
}} | }} | ||
{{tag|test}} | {{tag|test}} | ||
Latest revision as of 10:52, 10 August 2016
TDD:
- is an approach that combines test-first development (TFD) and refactor code;
- writes a test before it writes the code—the test in effect does double duty in that it both specifies and validates that piece of code;
- can be used to specify detailed requirements on a just-in-time (JIT) basis throughout construction—writing the acceptance test is the documentation; a.k.a. acceptance test-driven development or behavior-driven development;
- makes small changes to a product that do not change its semantics—in other words, refactor code is a clean-up activity that makes something better but does not add or subtract functionality;