{"id":2530,"date":"2015-12-05T17:11:36","date_gmt":"2015-12-06T01:11:36","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&#038;p=2530"},"modified":"2023-10-18T12:40:40","modified_gmt":"2023-10-18T19:40:40","slug":"tdd","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/tdd\/","title":{"rendered":"TDD"},"content":{"rendered":"<div>\n<p>\u201cTest-driven development\u201d refers to a style of programming in which three activities are tightly interwoven: coding, testing (in the form of writing\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/unit-test\/\">unit tests<\/a>), and design (in the form of <a href=\"https:\/\/agilealliance.org\/glossary\/refactoring\/\">refactoring<\/a>).<\/p>\n<p>It can be succinctly described by the following set of rules:<\/p>\n<ul>\n<li>write a \u201csingle\u201d unit test describing an aspect of the program<\/li>\n<li>run the test, which should fail because the program lacks that feature<\/li>\n<li>write \u201cjust enough\u201d code, the simplest possible, to make the test pass<\/li>\n<li>\u201crefactor\u201d the code until it conforms to the\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/rules-of-simplicity\/\">simplicity criteria<\/a><\/li>\n<li>repeat, \u201caccumulating\u201d unit tests over time<\/li>\n<\/ul>\n<\/div>\n<h2>Expected Benefits<\/h2>\n<div>\n<div>\n<ul>\n<li>many teams report significant reductions in defect rates, at the cost of a moderate increase in an initial development effort<\/li>\n<li>the same teams tend to report that these overheads are more than offset by a reduction in effort in projects\u2019 final phases<\/li>\n<li>although empirical research has so far failed to confirm this, veteran practitioners report that TDD leads to improved design qualities in the code, and more generally a higher degree of \u201cinternal\u201d or technical quality, for instance improving the metrics of cohesion and coupling<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h2>Common Pitfalls<\/h2>\n<div>\n<div>\n<p>Typical individual mistakes include:<\/p>\n<ul>\n<li>forgetting to run tests frequently<\/li>\n<li>writing too many tests at once<\/li>\n<li>writing tests that are too large or coarse-grained<\/li>\n<li>writing overly trivial tests, for instance omitting assertions<\/li>\n<li>writing tests for trivial code, for instance, accessors<\/li>\n<\/ul>\n<p>Typical team pitfalls include:<\/p>\n<ul>\n<li>partial adoption \u2013 only a few developers on the team use TDD<\/li>\n<li>poor maintenance of the test suite \u2013 most commonly leading to a test suite with a prohibitively long running time<\/li>\n<li>the abandoned test suite (i.e. seldom or never run) \u2013 sometimes as a result of poor maintenance, sometimes as a result of team turnover<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h2>Origins<\/h2>\n<div>\n<div>\n<p>While the idea of having test elaboration precede programming is not original to the Agile community, TDD constitutes a breakthrough insofar as it combines that idea with that of \u201cdeveloper testing\u201d, providing developer testing with renewed respectability.<\/p>\n<ul>\n<li>1976: publication of \u201c<a href=\"http:\/\/www.amazon.fr\/dp\/0471627658\">Software Reliability<\/a>\u201d by Glenford Myers, which states as an \u201caxiom\u201d that \u201ca developer should never test their own code\u201d (Dark Ages of Developer Testing)<\/li>\n<li>1990: testing discipline dominated by \u201cblack box\u201d techniques, in particular in the form of \u201ccapture and replay\u201d testing tools<\/li>\n<li>1991: independent creation of a testing framework at Taligent with striking similarities to SUnit (<a href=\"http:\/\/shebanator.com\/2007\/08\/21\/a-brief-history-of-test-frameworks\/\">source<\/a>)<\/li>\n<li>1994: Kent Beck writes the SUnit testing framework for Smalltalk (<a href=\"http:\/\/www.macqueen.us\/smalltalkReport\/ST\/91_95\/SMAL0402.PDF\">source<\/a>)<\/li>\n<li>1998: article on\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/xp\/\">Extreme Programming<\/a>\u00a0mentions that \u201cwe usually write the test first\u201d (<a href=\"http:\/\/www.xprogramming.com\/publications\/dc9810cs.pdf\">source<\/a>)<\/li>\n<li>1998 to 2002: \u201cTest First\u201d is elaborated into \u201cTest Driven\u201d, in particular on the\u00a0<a href=\"http:\/\/c2.com\/cgi\/wiki?TestDrivenDevelopment\">C2.com<\/a>\u00a0Wiki<\/li>\n<li>2000:\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/mocks\/\">Mock Objects<\/a>\u00a0are among the novel techniques developed during that period (<a href=\"http:\/\/www.mockobjects.com\/files\/endotesting.pdf\">source<\/a>)<\/li>\n<li>2003: publication of \u201c<a href=\"http:\/\/www.amazon.fr\/dp\/0321146530\">Test Driven Development: By Example<\/a>\u201d by Kent Beck<\/li>\n<\/ul>\n<p>By 2006 TDD is a relatively mature discipline which has started encouraging further innovations derived from it, such as\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/atdd\/\">ATDD<\/a>\u00a0or\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/bdd\/\">BDD<\/a>).<\/p>\n<\/div>\n<\/div>\n<h2>Signs of Use<\/h2>\n<div>\n<div>\n<ul>\n<li><a href=\"http:\/\/en.wikipedia.org\/wiki\/Code_coverage\">\u201ccode coverage\u201d<\/a>\u00a0is a common approach to evidencing the use of TDD; while high coverage does not guarantee appropriate use of TDD, coverage below 80% is likely to indicate deficiencies in a team\u2019s mastery of TDD<\/li>\n<li><a href=\"https:\/\/agilealliance.org\/glossary\/version-control\/\">version control<\/a>\u00a0logs should show that test code is checked in each time product code is checked in, in roughly comparable amounts<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h2>Skill Levels<\/h2>\n<div>\n<div>\n<p>Beginner<\/p>\n<ul>\n<li>able to write a unit test prior to writing the corresponding code<\/li>\n<li>able to write code sufficient to make a failing test pass<\/li>\n<\/ul>\n<p>Intermediate<\/p>\n<ul>\n<li>practices \u201ctest driven bug fixing\u201d: when a defect is found, write a test exposing the defect before correction<\/li>\n<li>able to decompose a compound program feature into a sequence of several unit tests to be written<\/li>\n<li>knows and can name a number of tactics to guide the writing of tests (for instance \u201cwhen testing a recursive algorithm, first write a test for the recursion terminating case\u201d)<\/li>\n<li>able to factor out reusable elements from existing unit tests, yielding situation-specific testing tools<\/li>\n<\/ul>\n<p>Advanced<\/p>\n<ul>\n<li>able to formulate a \u201croadmap\u201d of planned unit tests for macroscopic features (and revise it as necessary)<\/li>\n<li>able to \u201ctest drive\u201d a variety of design paradigms: object-oriented, functional, event-drive<\/li>\n<li>able to \u201ctest drive\u201d a variety of technical domains: computation, user interfaces, persistent data access, etc.<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h2>Further Reading<\/h2>\n<div>\n<div>\n<p><a href=\"http:\/\/amzn.to\/29GVe75\" target=\"_blank\" rel=\"noopener noreferrer\">Test Driven Development: By Example<\/a>, by Kent Beck<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven.  Benefits include reduction in defect rates.<\/p>\n","protected":false},"author":8027401,"featured_media":8067461,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","categories":[906],"tags":[],"class_list":["post-2530","aa_glossary","type-aa_glossary","status-publish","has-post-thumbnail","hentry","category-technology"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/2530","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/aa_glossary"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/8027401"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=2530"}],"version-history":[{"count":0,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/2530\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8067461"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=2530"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=2530"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=2530"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}