#readwise # Test-Driven Development - Wikipedia  ## Metadata - Author: [[en.wikipedia.org]] - Full Title: Test-Driven Development - Wikipedia - URL: https://en.wikipedia.org/wiki/Test-driven_development ## Highlights - Test-driven development (TDD) is a software development process relying on **software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is as opposed to software being developed first and test cases created later.** ^qgnkxb - Test-driven development offers **more than just simple validation of correctness, but can also drive the design of a program. By focusing on the test cases first, one must imagine how the functionality is used by clients (in the first case, the test cases). So, the programmer is concerned with the interface before the implementation.** This benefit is complementary to design by contract as it approaches code through test cases rather than through mathematical assertions or preconceptions. - While it is true that more code is required with TDD than without TDD because of the unit test code, the total code implementation time could be shorter based on a model by Müller and Padberg. **Large numbers of tests help to limit the number of defects in the code. The early and frequent nature of the testing helps to catch defects early in the development cycle, preventing them from becoming endemic and expensive problems. Eliminating defects early in the process usually avoids lengthy and tedious debugging later in the project.** - Note: citation from Müller, Matthias M.; Padberg, Frank. ["About the Return on Investment of Test-Driven Development"](https://web.archive.org/web/20171108092303/https://pdfs.semanticscholar.org/65d9/24ef1162b2f3c24bd15d627302887991b298.pdf) (PDF). Universität Karlsruhe, Germany: 6. [S2CID](https://en.wikipedia.org/wiki/S2CID_(identifier) "S2CID (identifier)") [13905442](https://api.semanticscholar.org/CorpusID:13905442). Archived from [the original](https://pdfs.semanticscholar.org/65d9/24ef1162b2f3c24bd15d627302887991b298.pdf) (PDF) on 2017-11-08. Retrieved 2012-06-14. - **TDD can lead to more modularized, flexible, and extensible code.** This effect often comes about because the methodology requires that the developers think of the software in terms of small units that can be written and tested independently and integrated together later. This leads to smaller, **more focused classes, looser coupling, and cleaner interfaces.** The use of the mock object design pattern also contributes to the overall modularization of the code because this pattern **requires that the code be written so that modules can be switched easily between mock versions for unit testing and "real" versions for deployment.** - Because no more code is written than necessary to pass a failing test case, **automated tests tend to cover every code path**. For example, for a TDD developer to add an else branch to an existing if statement, the developer would first have to write a failing test case that motivates the branch. As a result, the automated tests resulting from TDD tend to be very thorough: they detect any unexpected changes in the code's behaviour. This detects problems that can arise where a change later in the development cycle unexpectedly alters other functionality.