In computer programming, unit testing is a software testing method by which individual
units of source code, sets of one or more computer program modules together with associated
control data, usage procedures, and operating procedures are tested to determine if they
are fit for use.
Intuitively, one can view a unit as the smallest testable part of an application.
In procedural programming, a unit could be an entire module, but it is more commonly
an individual function or procedure.
In object-oriented programming, a unit is often an entire interface, such as a class,
but could be an individual method.
Unit tests are short code fragments created by programmers or occasionally by white box
testers during the development process.
Ideally, each test case is independent from the others.
Substitutes such as method stubs, mock objects, fakes, and test harnesses can be used to assist
testing a module in isolation.
Unit tests are typically written and run by software developers to ensure that code meets
its design and behaves as intended.
Benefits The goal of unit testing is to isolate each
part of the program and show that the individual parts are correct.
A unit test provides a strict, written contract that the piece of code must satisfy.
As a result, it affords several benefits.
Finds problems early Unit testing finds problems early in the development
cycle.
In test-driven development, which is frequently used in both Extreme Programming and Scrum,
unit tests are created before the code itself is written.
When the tests pass, that code is considered complete.
The same unit tests are run against that function frequently as the larger code base is developed
either as the code is changed or via an automated process with the build.
If the unit tests fail, it is considered to be a bug either in the changed code or the
tests themselves.
The unit tests then allow the location of the fault or failure to be easily traced.
Since the unit tests alert the development team of the problem before handing the code
off to testers or clients, it is still early in the development process.
Facilitates change Unit testing allows the programmer to refactor
code at a later date, and make sure the module still works correctly.
The procedure is to write test cases for all functions and methods so that whenever a change
causes a fault, it can be quickly identified.
Readily available unit tests make it easy for the programmer to check whether a piece
of code is still working properly.
In continuous unit testing environments, through the inherent practice of sustained maintenance,
unit tests will continue to accurately reflect the intended use of the executable and code
in the face of any change.
Depending upon established development practices and unit test coverage, up-to-the-second accuracy
can be maintained.
Simplifies integration Unit testing may reduce uncertainty in the
units themselves and can be used in a bottom-up testing style approach.
By testing the parts of a program first and then testing the sum of its parts, integration
testing becomes much easier.
An elaborate hierarchy of unit tests does not equal integration testing.
Integration with peripheral units should be included in integration tests, but not in
unit tests.
Integration testing typically still relies heavily on humans testing manually; high-level
or global-scope testing can be difficult to automate, such that manual testing often appears
faster and cheaper.
Documentation Unit testing provides a sort of living documentation
of the system.
Developers looking to learn what functionality is provided by a unit and how to use it can
look at the unit tests to gain a basic understanding of the unit's interface.
Unit test cases embody characteristics that are critical to the success of the unit.
These characteristics can indicate appropriate/inappropriate use of a unit as well as negative behaviors
that are to be trapped by the unit.
A unit test case, in and of itself, documents these critical characteristics, although many
software development environments do not rely solely upon code to document the product in
development.
Design When software is developed using a test-driven
approach, the combination of writing the unit test to specify the interface plus the refactoring
activities performed after the test is passing, may take the place of formal design.
Each unit test can be seen as a design element specifying classes, methods, and observable
behaviour.
The following Java example will help illustrate this point.
Here is a set of test cases that specify a number of elements of the implementation.
First, that there must be an interface called Adder, and an implementing class with a zero-argument
constructor called AdderImpl.
It goes on to assert that the Adder interface should have a method called add, with two
integer parameters, which returns another integer.
It also specifies the behaviour of this method for a small range of values over a number
of test methods.
In this case the unit tests, having been written first, act as a design document specifying
the form and behaviour of a desired solution, but not the implementation details, which
are left for the programmer.
Following the "do the simplest thing that could possibly work" practice, the easiest
solution that will make the test pass is shown below.
Unlike other diagram-based design methods, using unit-tests as a design specification
has one significant advantage.
The design document can be used to verify that the implementation adheres to the design.
With the unit-test design method, the tests will never pass if the developer does not
implement the solution according to the design.
It is true that unit testing lacks some of the accessibility of a diagram, but UML diagrams
are now easily generated for most modern languages by free tools.
Free tools, like those based on the xUnit framework, outsource to another system the
graphical rendering of a view for human consumption.
Separation of interface from implementation Because some classes may have references to
other classes, testing a class can frequently spill over into testing another class.
A common example of this is classes that depend on a database: in order to test the class,
the tester often writes code that interacts with the database.
This is a mistake, because a unit test should usually not go outside of its own class boundary,
and especially should not cross such process/network boundaries because this can introduce unacceptable
performance problems to the unit test-suite.
Crossing such unit boundaries turns unit tests into integration tests, and when test cases
fail, makes it less clear which component is causing the failure.
See also Fakes, mocks and integration tests Instead, the software developer should create
an abstract interface around the database queries, and then implement that interface
with their own mock object.
By abstracting this necessary attachment from the code, the independent unit can be more
thoroughly tested than may have been previously achieved.
This results in a higher quality unit that is also more maintainable.
Parameterized unit testing Parameterized unit tests are tests that take
parameters.
Unlike traditional unit tests, which are usually closed methods, PUTs take any set of parameters.
PUTs have been supported by TestNG, JUnit and various .NET test frameworks.
Suitable parameters for the unit tests may be supplied manually or in some cases are
automatically generated by the test framework.
Testing tools QuickCheck exist to generate test inputs for PUTs.
Unit testing limitations Testing will not catch every error in the
program, since it cannot evaluate every execution path in any but the most trivial programs.
The same is true for unit testing.
Additionally, unit testing by definition only tests the functionality of the units themselves.
Therefore, it will not catch integration errors or broader system-level errors.
Unit testing should be done in conjunction with other software testing activities, as
they can only show the presence or absence of particular errors; they cannot prove a
complete absence of errors.
In order to guarantee correct behavior for every execution path and every possible input,
and ensure the absence of errors, other techniques are required, namely the application of formal
methods to proving that a software component has no unexpected behavior.
Software testing is a combinatorial problem.
For example, every boolean decision statement requires at least two tests: one with an outcome
of "true" and one with an outcome of "false".
As a result, for every line of code written, programmers often need 3 to 5 lines of test
code.
This obviously takes time and its investment may not be worth the effort.
There are also many problems that cannot easily be tested at all – for example those that
are nondeterministic or involve multiple threads.
In addition, code for a unit test is likely to be at least as buggy as the code it is
testing.
Fred Brooks in The Mythical Man-Month quotes: "Never go to sea with two chronometers; take
one or three."
Meaning, if two chronometers contradict, how do you know which one is correct?
Another challenge related to writing the unit tests is the difficulty of setting up realistic
and useful tests.
It is necessary to create relevant initial conditions so the part of the application
being tested behaves like part of the complete system.
If these initial conditions are not set correctly, the test will not be exercising the code in
a realistic context, which diminishes the value and accuracy of unit test results.
To obtain the intended benefits from unit testing, rigorous discipline is needed throughout
the software development process.
It is essential to keep careful records not only of the tests that have been performed,
but also of all changes that have been made to the source code of this or any other unit
in the software.
Use of a version control system is essential.
If a later version of the unit fails a particular test that it had previously passed, the version-control
software can provide a list of the source code changes that have been applied to the
unit since that time.
It is also essential to implement a sustainable process for ensuring that test case failures
are reviewed daily and addressed immediately.
If such a process is not implemented and ingrained into the team's workflow, the application
will evolve out of sync with the unit test suite, increasing false positives and reducing
the effectiveness of the test suite.
Unit testing embedded system software presents a unique challenge: Since the software is
being developed on a different platform than the one it will eventually run on, you cannot
readily run a test program in the actual deployment environment, as is possible with desktop programs.
Applications Extreme programming
Unit testing is the cornerstone of extreme programming, which relies on an automated
unit testing framework.
This automated unit testing framework can be either third party, e.g., xUnit, or created
within the development group.
Extreme programming uses the creation of unit tests for test-driven development.
The developer writes a unit test that exposes either a software requirement or a defect.
This test will fail because either the requirement isn't implemented yet, or because it intentionally
exposes a defect in the existing code.
Then, the developer writes the simplest code to make the test, along with other tests,
pass.
Most code in a system is unit tested, but not necessarily all paths through the code.
Extreme programming mandates a "test everything that can possibly break" strategy, over the
traditional "test every execution path" method.
This leads developers to develop fewer tests than classical methods, but this isn't really
a problem, more a restatement of fact, as classical methods have rarely ever been followed
methodically enough for all execution paths to have been thoroughly tested.
Extreme programming simply recognizes that testing is rarely exhaustive and provides
guidance on how to effectively focus limited resources.
Crucially, the test code is considered a first class project artifact in that it is maintained
at the same quality as the implementation code, with all duplication removed.
Developers release unit testing code to the code repository in conjunction with the code
it tests.
Extreme programming's thorough unit testing allows the benefits mentioned above, such
as simpler and more confident code development and refactoring, simplified code integration,
accurate documentation, and more modular designs.
These unit tests are also constantly run as a form of regression test.
Unit testing is also critical to the concept of emergent design.
As emergent design is heavily dependent upon refactoring, unit tests are an integral component.
Techniques Unit testing is commonly automated, but may
still be performed manually.
The IEEE does not favor one over the other.
The objective in unit testing is to isolate a unit and validate its correctness.
A manual approach to unit testing may employ a step-by-step instructional document.
However, automation is efficient for achieving this, and enables the many benefits listed
in this article.
Conversely, if not planned carefully, a careless manual unit test case may execute as an integration
test case that involves many software components, and thus preclude the achievement of most
if not all of the goals established for unit testing.
To fully realize the effect of isolation while using an automated approach, the unit or code
body under test is executed within a framework outside of its natural environment.
In other words, it is executed outside of the product or calling context for which it
was originally created.
Testing in such an isolated manner reveals unnecessary dependencies between the code
being tested and other units or data spaces in the product.
These dependencies can then be eliminated.
Using an automation framework, the developer codes criteria into the test to verify the
unit's correctness.
During test case execution, the framework logs tests that fail any criterion.
Many frameworks will also automatically flag these failed test cases and report them in
a summary.
Depending upon the severity of a failure, the framework may halt subsequent testing.
As a consequence, unit testing is traditionally a motivator for programmers to create decoupled
and cohesive code bodies.
This practice promotes healthy habits in software development.
Design patterns, unit testing, and refactoring often work together so that the best solution
may emerge.
Unit testing frameworks
Unit testing frameworks are most often third-party products that are not distributed as part
of the compiler suite.
They help simplify the process of unit testing, having been developed for a wide variety of
languages.
Examples of testing frameworks include open source solutions such as the various code-driven
testing frameworks known collectively as xUnit, and proprietary/commercial solutions such
as TBrun, JustMock, Isolator.NET, Isolator++, Parasoft Development Testing, Testwell CTA++
and VectorCAST/C++.
It is generally possible to perform unit testing without the support of a specific framework
by writing client code that exercises the units under test and uses assertions, exception
handling, or other control flow mechanisms to signal failure.
Unit testing without a framework is valuable in that there is a barrier to entry for the
adoption of unit testing; having scant unit tests is hardly better than having none at
all, whereas once a framework is in place, adding unit tests becomes relatively easy.
In some frameworks many advanced unit test features are missing or must be hand-coded.
Language-level unit testing support Some programming languages directly support
unit testing.
Their grammar allows the direct declaration of unit tests without importing a library.
Additionally, the boolean conditions of the unit tests can be expressed in the same syntax
as boolean expressions used in non-unit test code, such as what is used for if and while
statements.
Languages that directly support unit testing include:
ABAP C#
D Go
Java Obix
Python Ruby
Scala Objective-C
See also
Acceptance testing Characterization test
Component-Based Usability Testing Design predicates
Design by contract Extreme programming
Integration testing List of unit testing frameworks
Unit testing frameworks for Ruby Regression testing
Software archaeology Software testing
Test case Test-driven development
xUnit – a family of unit testing frameworks.
Notes
External links Test Driven Development