Test-driven development

From Free net encyclopedia

Test-Driven Development (TDD) is a computer programming technique that involves writing test cases first and then implementing the code necessary to pass the tests. The goal of test-driven development is to achieve rapid feedback and implements the "illustrate the main line" approach to constructing a program. This technique is heavily emphasized in Extreme Programming.

Practitioners emphasize that test-driven development is primarily a method of designing software, not just a method of testing. The method is also used for removal of software defects.

Contents

[edit]

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, NUnit or CPPUnit provide a mechanism for managing and running sets of automated test cases.

[edit]

Test-Driven Development Cycle

[edit]

1. Write the test

It begins with writing a test. In order to write a test, the developer must understand the specification and the requirements clearly. This is accomplished through use cases and user stories. The design document covers all the test scenarios and exception conditions.

[edit]

2. Write the code

The next step is to make the test pass by writing the code. This step forces the programmer to take the perspective of a client by seeing the code through its interfaces. This is the design driven part of test-driven development. As part of test calibration, your code should fail the test meaningfully the first time around.

[edit]

3. Run the automated tests

The next step is to run the automated test cases and observe if they pass or fail. If they pass, the programmer can be more confident that the code meets the test cases as written. If there are failures, the code did not meet the test cases..

[edit]

4. Refactor

The final step is the refactoring step and any code clean-up necessary will occur here. The test cases are then re-run and observed.

[edit]

5. Repeat

The cycle will then repeat itself and start with either adding additional functionality or fixing any errors.

[edit]

Differing styles

There are various ways one can go about using test-driven development and the most common one is based on the principles of "Keep It Simple, Stupid" (KISS) and "You Ain't Gonna Need It" (YAGNI). This style focuses on writing only the code necessary to pass the tests. Design and property principles are cast aside in the name of simplicity and speed. Therefore, any rule can be violated as long as the tests will pass. This can be unsettling for many at first but it will allow the programmer to focus only on what is important. However, the programmer must pay a bigger fee in the refactoring step of the cycle since the code must be cleaned up to a reasonable level at this point before the cycle can restart.

Another variation of test-driven development requires the programmer to first fail the test cases. The idea is to ensure that the testcase really works and can catch an error. Once this is shown, the normal cycle will commence. This is one of the more popular variations and has been coined the "Test-Driven Development Mantra", known as red/green/refactor where red means fail and green is pass.

A third variation combines the first and second steps listed above. In this manner, the code is written inline and debugged as a part of the test. At this stage, the test will be very large, but will complete correctly and the test logic will contain the eventual program code. Then the actual program code is moved to the code tree using a "extract method" refactoring with a destination in the actual code tree. In this step, the test becomes substantially smaller, and the pre-tested method is created in the code tree. If this style is used with a code coverage tool, the final step is to ensure that the tests sufficiently exercise the code to achieve the code coverage desired by engineering management.

[edit]

Benefits

Despite the initial requirements, test-driven development can provide great value to building software better and faster. It 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 will be used by clients (in this case, the test cases). Therefore, the programmer is only concerned with the interface and not the implementation. This benefit is complementary to Design by Contract as approaches it through test cases rather than mathematical assertions.

The power test-driven development offers is the ability to take small steps when required. It allows a programmer to focus on the task at hand and often the first goal is to make the test pass. Exceptional cases and error handling are not considered initially. These extraneous circumstances are implemented after the main functionality has been achieved. Another advantage is that test-driven development, when used properly, ensures that all written code is covered by a test. This can give the programmer a greater level of trust in the code.

[edit]

Limitations

Test-driven development cannot work in an environment where automated testing is not feasible. The technique is immature and faces a variety of problems in the following areas:

It is also important to note that test-driven development only proves correctness of design and functionality according to the test cases 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 test cases since they are the drivers. As a result, test-driven development is only as good as the tests are.

[edit]

See also

[edit]

External links

es:Tdd ja:テストファースト ru:Разработка через тестирование zh:测试驱动开发

Retrieved from "http://www.netipedia.com/index.php/Test-driven_development"