Test-driven development: Difference between revisions

Revision as of 02:20, 30 September 2005

Revision as of 20:32, 21 October 2005

Line 1:

'''Test-driven development''' (TDD) is a programming technique heavily emphasized in [[Extreme Programming]]. Essentially the technique involves writing your tests first then implementing the code to make them pass. The goal of TDD is to achieve rapid feedback and implements the "illustrate the main line" approach to constructing a program.

It is good toPractitioners emphasize the fact that TDD '''is not''' primarily a method of testing, but rather a '''method of designing''' software.

== Requirements ==

For Test Driven Development to work, the system must be flexible enough to allow for [[automated testing]] of code, using test cases that return a simple true or false evaluation of correctness. These properties allow for rapid feedback of correctness and design. Unit testing frameworks such as [[JUnit]] provide a mechanism for managing and running sets of automated test cases.

== Test-Driven Development Cycle ==

Line 37 ⟶ 38:

TDD cannot work in an environment where [[automated testing]] is not feasible. It is currently immature and faces a variety of problems.

* GUI (although there are proposed partial solutions)

* GUI

* Distributed Objects (although mock objects can help)

* Database Schema

* Compilers and Interpreters from BNF to production quality implementation

* Some artificial intelligence and pattern recognition algorithms

* Some genetic algorithms

It is also important to note that Test-driven Development only proves correctness of design and functionality according to the testcases written. An incorrect testcase that does not meet the specifications will produce incorrect code. Therefore, the emphasis on correctness and design has shifted to writing testcases since they are the drivers. As a result, Test-driven Development is only as good as the tests are.