Editing Test-driven development (section)

=== Limitations ===
{{more citations needed section|date=August 2013}}
Test-driven development does not perform sufficient testing in situations where full functional tests are required to determine success or failure, due to extensive use of unit tests.<ref>
{{cite web
 | url=http://dalkescientific.com/writings/diary/archive/2009/12/29/problems_with_tdd.html
 | title=Problems with TDD
 | publisher=Dalkescientific.com
 | date=2009-12-29
 | access-date=2014-03-25}}</ref> Examples of these are [[user interface]]s, programs that work with [[database]]s, and some that depend on specific [[Computer network|network]] configurations. TDD encourages developers to put the minimum amount of code into such modules and to maximize the logic that is in testable library code, using fakes and [[Mock object|mocks]] to represent the outside world.<ref>
{{cite web
 | last=Hunter
 | first=Andrew
 | url=https://www.simple-talk.com/dotnet/.net-framework/are-unit-tests-overused/
 | title=Are Unit Tests Overused?
 | work=Simple Talk
 | publisher=Simple-talk.com
 | date=2012-10-19 |access-date=2014-03-25}}</ref>

Management support is essential. Without the entire organization believing that test-driven development is going to improve the product, management may feel that time spent writing tests is wasted.<ref>
{{cite web
 | url=http://people.apache.org/~stevel/slides/testing.pdf
 | title=Testing
 | last=Loughran
 | first=Steve
 | date=November 6, 2006
 | publisher=HP Laboratories
 | access-date=2009-08-12
 }}</ref>

Unit tests created in a test-driven development environment are typically created by the developer who is writing the code being tested. Therefore, the tests may share blind spots with the code: if, for example, a developer does not realize that certain input parameters must be checked, most likely neither the test nor the code will verify those parameters. Another example: if the developer misinterprets the requirements for the module they are developing, the code and the unit tests they write will both be wrong in the same way. Therefore, the tests will pass, giving a false sense of correctness.

A high number of passing unit tests may bring a false sense of security, resulting in fewer additional [[software testing]] activities, such as [[integration testing]] and [[compliance testing]].

Tests become part of the maintenance overhead of a project. Badly written tests, for example ones that include hard-coded error strings, are themselves prone to failure, and they are expensive to maintain. This is especially the case with [[fragile tests]].<ref>
{{cite web
 | url=http://xunitpatterns.com/Fragile%20Test.html
 | title=Fragile Tests
}}</ref> There is a risk that tests that regularly generate false failures will be ignored, so that when a real failure occurs, it may not be detected. It is possible to write tests for low and easy maintenance, for example by the reuse of error strings, and this should be a goal during the [[code refactoring]] phase described above.

Writing and maintaining an excessive number of tests costs time. Also, more-flexible modules (with limited tests) might accept new requirements without the need for changing the tests. For those reasons, testing for only extreme conditions, or a small sample of data, can be easier to adjust than a set of highly detailed tests.

The level of coverage and testing detail achieved during repeated TDD cycles cannot easily be re-created at a later date. Therefore, these original, or early, tests become increasingly precious as time goes by. The tactic is to fix it early. Also, if a poor architecture, a poor design, or a poor testing strategy leads to a late change that makes dozens of existing tests fail, then it is important that they are individually fixed. Merely deleting, disabling or rashly altering them can lead to undetectable holes in the test coverage.