Test-driven development

[3] Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

[4] Software engineer Kent Beck, who is credited with having developed or "rediscovered"[5] the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.

Therefore I refer to my role as "rediscovering" TDD.The TDD steps vary somewhat by author in count and description, but are generally as follows.

These are based on the book Test-Driven Development by Example,[6] and Kent Beck's Canon TDD article.

The six steps of the TDD sequence are applied with minor semantic changes: There are various aspects to using test-driven development, for example the principles of "keep it simple, stupid" (KISS) and "You aren't gonna need it" (YAGNI).

By focusing on writing only the code necessary to pass tests, designs can often be cleaner and clearer than is achieved by other methods.

[6] In Test-Driven Development by Example, Kent Beck also suggests the principle "Fake it till you make it".

Test-driven development constantly repeats the steps of adding test cases that fail, passing them, and refactoring.

Receiving the expected test results at each stage reinforces the developer's mental model of the code, boosts confidence and increases productivity.

In the .NET Framework and some other programming languages, partial classes may be used to expose private methods and data for the tests to access.

There is some debate among practitioners of TDD, documented in their blogs and other writings, as to whether it is wise to test private methods and data anyway.

Some argue that private members are a mere implementation detail that may change, and should be allowed to do so without breaking numbers of tests.

In a fault mode, a method may return an invalid, incomplete or null response, or may throw an exception.

To avoid errors that may arise from this, other tests are needed that instantiate the test-driven code with the "real" implementations of the interfaces discussed above.

This is often achieved using some combination of the following techniques: For TDD, a unit is most commonly defined as a class, or a group of related functions often called a module.

With ATDD, the development team now has a specific target to satisfy – the acceptance tests – which keeps them continuously focused on what the customer really wants from each user story.

Test code must work correctly for both positive and negative cases, last a long time, and be readable and maintainable.

[20] TDD is primarily a developer's tool to help create well-written unit of code (function, class, or module) that correctly performs a set of operations.

These proven practices yield increased testability and facilitate the application of build and test automation.

The Scenario Model provides an excellent vehicle for creating the strategy of interactions between components in response to a specific stimulus.

[26] Programmers using pure TDD on new ("greenfield") projects reported they only rarely felt the need to invoke a debugger.

This benefit is complementary to design by contract as it approaches code through test cases rather than through mathematical assertions or preconceptions.

Exceptional cases and error handling are not considered initially, and tests to create these extraneous circumstances are implemented separately.

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.

[38] Examples of these are user interfaces, programs that work with databases, and some that depend on specific network configurations.

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.

Badly written tests, for example ones that include hard-coded error strings, are themselves prone to failure, and they are expensive to maintain.

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.

The level of coverage and testing detail achieved during repeated TDD cycles cannot easily be re-created at a later date.

Merely deleting, disabling or rashly altering them can lead to undetectable holes in the test coverage.