Test-driven development

Test-driven development (including test-driven programming, Eng. Development test first or test- driven development ( TDD) ) is a method that is widely used in the agile development of computer programs. In the test-driven development, the programmer creates software testing consistently ahead of the components to be tested. The test cases created to be referred to as gray box tests.

• 5.1 consequence is necessary
• 5.2 No substitute for system testing

Reasons for the introduction of a test-driven development

Following a classical approach, for example, according to the waterfall or V- model tests are parallel to and independent of the system under test developed or even after him. This often leads to not have the desired and required test coverage is achieved. Possible reasons for this include:

• Missing or lack of testability of the system ( monolithic, use of third-party components, ...).
• Prohibition of investment in non-functional parts of the program on the part of corporate management. ( " Work of the one in the program does not see later, is wasted. " )
• Creating tests under time pressure.
• Negligence and lack of discipline of the programmer in test creation.

Another disadvantage of classical white-box testing is that the developer is familiar with the system under test and its peculiarities themselves, thereby from blindness unexpectedly " errors around " test.

The method of test-driven development is trying to counter the reasons for an inadequate test coverage and some disadvantages of the white-box testing.

Method

In the test-driven development between testing on a small scale ( unit testing ) and testing in the Great ( system tests, acceptance tests) is to be distinguished, with Beck's method is designed for unit testing.

Test-driven development with unit tests

Unit tests and tested with them Units are always developed in parallel. The actual programming is done in small and repeated microiterations. Such iteration, which should take only a few minutes, has three main parts:

These three steps are repeated until the desired functionality is reached or the known error is adjusted and the developers come up with any meaningful further testing that might still fail. The thus treated program unit (Unit) is regarded as finished (for now). Remember The tests created together with her get to test and future implementations may then, if the desired behavior persists.

Complying with this approach amounts to evolutionary design because the constant change focuses on the development of a system to the forefront.

Since the single unit test has both features of a White- box testing as well as a black-box testing, it is referred to as gray box testing.

Test-driven development with system testing

System tests are being developed before the system itself, or at least specified. Task of system development is in test-driven development is no longer to fulfill as classic, formulated in writing requirements, but to insist specified system tests.

Similarities between test -driven development with system testing and unit testing

In both types of tests, a complete as possible test automation is aimed at. For test-driven development, testing must just ( " push-button " ) and can be performed as quickly as possible. For unit tests, this means a duration of a few seconds for system testing of up to several minutes or longer only in exceptions.

The major benefits of test-driven methodology over classical are:

• One has a nontrivial metric for the fulfillment of the requirements: passed the tests or not.
• Refactoring, ie cleaning up the code, resulting in fewer errors; because to attain this in small steps and always along passing test, there arise a few new ones, and they are better localized.
• As can be tested easily and without great expenditure of time, the programmers most of the time working on a proper system, and so with confidence and focused attention to the current subtask. ( No " crossing the desert ", not "everything depends on everything " )
• The inventory of unit tests documented the system at the same time. It generates namely at the same time a " executable specification " - the use of the software system, is in the form both readable as well as any time executable tests.
• A test -driven approach results in the tendency to code that is more modularized and easier to modify and extend. Because this creates the planned system of small units of work that are independently written and tested, but so later from a developer's point of view. The corresponding software entities ( classes, modules, ...) are so small, more specifically, their coupling is looser and their interfaces simple. If you use even mock objects, it also forces simply to keep dependency structures, because otherwise it would not be the essential fast and loose maternity replacement of modules for testing and for production code possible.

Areas of application

Test-driven development is an essential part of Extreme Programming (XP ) and other agile methods. Even outside of this it can be found, often in conjunction with the pair programming. As an exercise method katas are often used.

Tools

The test-driven development requires urgent

• A tool for build automation such as CruiseControl or Jenkins
• A framework and a tool for test development and automation,

So that the iterations can be run through quickly and easily.

In the Java development for Ant or Maven and usually come JUnit used. For most other programming languages ​​there are similar tools such as PHPUnit for PHP.

For complex systems, several sub-components need to be developed independently of each other and find it to also use third-party components, such as a database system for the purpose of persistent data storage. The correct co-operation and function of the components in the system then needs to be tested. In order to test the individual components separately here, but the but depend for their correct function significantly from other components, using mock objects as their deputies. Replace the mock objects and simulate test in the required other components in a way that is programmed into the tester them.

Criticism

Consequence is necessary

Also, the method of test-driven development can be used incorrectly and then fail. Programmers who do not have any experience doing, they appear sometimes difficult or even impossible. You wonder how to test something that is still non-existent. Effect may be that they neglect the principles of this method, which for agile methods such as Extreme Programming difficulties in the development process or even its collapse can in particular also be impaired. Without sufficient unit tests no sufficient test coverage for refactoring and the desired quality is achieved. This can be countered with pair programming and training.

No replacement for system testing

These strong pathways consisting of tests kind of programming can not uncover any errors, especially errors resulting program external: timing errors such as thread deadlocks, errors in interface communication etc. Also may lack the necessary test coverage if not all potential inputs of a function can be tested. This is the case when the input of very many individual data; then can expense half no longer be tested every possible combination of input data. Error Benutzungsoberfächen are poorly testable, because of course, no automated, be tested " test view" of the sequence of screen displays and the intelligibility of representation and text elements is possible. To find such errors, integration testing and system testing are recommended. However, these types of tests can not detect all errors, therefore several types of tests should be used in most cases.