CSC/ECE 517 Fall 2013/ch1 1w31 vm

Test Driven Development (Under Construction)

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence. Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right. Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

Rules of Thumb

Don’t write a line of new code unless you first have a failing automated test

Eliminate duplication. These rules generate complex individual and group behavior. Some of the technical implications are:

Design with organization

TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

Write your own tests

This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

Rapid Response

Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

High Cohesion

In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.