Unit testing

A module test (also unit test or often from the English. Unittest as a unit test called ) is applied in software development to test the functional items ( ' modules ') of computer programs, that is, to check for correct functionality.

The term module test is seen as an early stage of the test in which the inner most detailed components of the software to be tested. See also the graphic ' stages of the V- model ' and V - model (after Barry Boehm).

Classification in the testing process

Since algorithms at the module level usually have only a limited complexity and are activated via clearly defined interfaces, they can largely be fully tested with relatively few test cases. This is a prerequisite for the subsequent test level integration test order to be able to align the test cases on the integrated cooperation of major functional parts or the entire application; The module-specific detail constellations can be so locations are limited to sampling, which reduces the number of required test cases dramatically.

For comparison, a device is only tested as a whole when the functioning of its parts is considered certain.

Test techniques

Take from the spectrum of the numerous types of tests / test techniques for unit testing on particularly the following. A unit test is so for example ( several options ):

Method for test case definition

Module tests among the white-box testing. That is, in the definition of the test cases to test the source code are known. The specification of the software is only used for determining the desired results. In principle, all source code parts have to be executed at least once. Statement coverage, branch coverage and path coverage can help determine this, which test cases in the theory are the minimum required for this purpose (see control flow -oriented test procedure). In practice, one usually tries to achieve the set target coverage with as few test cases, since all module tests must be maintained continuously.

Method for creating unit tests

Usually all module tests are based on a uniform basic structure. While (1) thereto (2) is first initialized, a starting state, running the tested operation, and finally (3) comparing the actual result with a desired value derived from the specification. For these comparisons provide the test framework "assert " methods ( German about: find insurance ) are available.

Properties of module tests

Isolation of test objects

Unit tests test a module in isolation, that is, largely without interaction with other modules. Why must or can other modules or external components such as a database, files, backend systems or sub-programs are simulated by auxiliary objects in unit testing, as far as the module to be tested ( DUT or test object) needs it. Complete test with all components in their original version should be performed in the subsequent integration and system tests - which possibly in the module test undetected errors (eg due to identical false assumptions for the test object and the auxiliary routine ) should be discovered.

Such auxiliary objects are implemented eg as a deputy and provided by means of inversion of control. A module can be tested usually easier than if all modules are already integrated, as in this case, pulled the dependence of the individual modules into consideration and handling in the test should be considered. Even thus isolated unit tests are already possible if others actually required components for the test are not yet available. Following auxiliary objects are known:

Test of the contract and not the algorithms

Unit tests do not test in accordance with the design -by -contract principle possible the internals of a method, but only its external impact ( return values, issues, changes of state, representations ). If the internal details of the method is checked ( this is called white-box testing), the test could fail even though the external effects have not changed. Therefore, in general the so-called black-box testing is recommended in which one is limited to checking the external effects.

Automated unit testing

With the proliferation of agile software development methods and particularly test-driven development, it has become customary to perform unit tests automated as possible. These frameworks are usually such as JUnit test programs written with the aid of test. About the test framework, the individual test classes are called and executed their unit tests. Most test frameworks provide a graphical summary of the test results.

Automated unit tests have the advantage that they performed simple and inexpensive and that new bugs can be found quickly. However, this requires inter alia that test scores from previous module tests are available and the actual test results can be compared with these.

Criticism

Module tests (such as each test ) do not guarantee or certify the correctness of the tested module, but only support. The limits of module tests are necessarily the fact that only those defects can be found, to their discovery, the tests used are appropriate. A software component, the " green " test, so is not necessarily error-free.

To test the feature code "green", and certainly the desire for this result could mean that actually (unconsciously ) is tested only so much that all tests " green " are. Modules that have no failing unit tests, to be treated as errors, is a common anti-pattern in practice test-driven development.

When changing code module testing to ensure that no such errors will be inserted unnoticed, revealing sure the entire portfolio of tests. The problem of producing a sufficient test coverage can only be solved by appropriate consideration and appropriate action.

If - as usually - the author of module tests is identical with the author of the modules, human error in the implementation can also appear in the test and will not be revealed. If it is the same person, this is also not excluded by the fact that the tests are developed first, since both the intended operation of the code, as well as its future shape may be already present in the mind of the author and later test code author.