Jump to content

xUnit

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Adam1213 (talk | contribs) at 08:41, 25 January 2014 (testing software is worthwhile and should be done. It is not mandatory). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.


When developing software, testing the software is a worthwhile step. One type of testing, unit testing, involves testing the fundamental units of the software. It may be carried out by writing code that tries out the target unit, checking inputs and outputs, one detail at a time. By keeping such automated testing code, programmers can verify that they haven't broken something along the way. Software to manage these tests are often called code-driven testing frameworks.

Various such frameworks have come to be known collectively as xUnit. These allow testing of different elements (units) of software, such as functions and classes. The main advantage of xUnit frameworks is that they provide an automated solution with no need to write the same tests many times, and no need to remember what should be the result of each test. These frameworks are based on a design by Kent Beck, originally implemented for Smalltalk as SUnit. Erich Gamma and Kent Beck ported SUnit to Java, creating JUnit. From there, the framework was also ported to other programming languages, e.g., CppUnit (for C++), NUnit (for .NET), MATLAB Unit Testing Framework. They are all referred to as xUnit and are usually free, open-source software.

xUnit architecture

All xUnit frameworks share the following basic component architecture, with some varied implementation details.

Test runner

A test runner is an executable program that runs tests implemented using an xUnit framework and reports the test results.[1]

Test case

A test case is the most elemental class. All unit tests are inherited from here.

Test fixtures

A test fixture (also known as a test context) is the set of preconditions or state needed to run a test. The developer should set up a known good state before the tests, and return to the original state after the tests.

Test suites

A test suite is a set of tests that all share the same fixture. The order of the tests shouldn't matter.

Test execution

The execution of an individual unit test proceeds as follows:

setup(); /* First, we should prepare our 'world' to make an isolated environment for testing */
...
/* Body of test - Here we make all the tests */
...
teardown(); /* In the end, whether succeed or fail we should clean up our 'world' to 
not disturb other tests or code */

The setup() and teardown() methods serve to initialize and clean up test fixtures.

Test result formatter

A test runner produces results in one or more output formats. In addition to a plain, human-readable format, there is often a test result formatter that produces XML output. The XML test result format originated with JUnit but is also used by some other xUnit testing frameworks, for instance build tools such as Jenkins and Atlassian Bamboo.

Assertions

An assertion is a function or macro that verifies the behavior (or the state) of the unit under test. Usually an assertion expresses a logical condition that is true for results expected in a correctly running system under test (SUT). Failure of an assertion typically throws an exception, aborting the execution of the current test.

xUnit frameworks

Many xUnit frameworks exist for various programming languages and development platforms.

See also

Unit testing in general:

Programming approach to unit testing:

References

  1. ^ Meszaros, Gerard (2007) xUnit Test Patterns, Pearson Education, Inc./Addison Wesley