...one of the most highly
regarded and expertly designed C++ library projects in the
world.
— Herb Sutter and Andrei
Alexandrescu, C++
Coding Standards
Several fixture interfaces are supported by the Unit Test Framework. The choice of the interface depends mainly on the usage of the fixture.
The Unit Test Framework defines the generic fixture class model as follows:
struct <fixture-name>{ <fixture-name>(); // setup function ~<fixture-name>(); // teardown function };
In other words a fixture is expected to be implemented as a class where
the class constructor serves as a setup
method and class destructor serves as teardown
method. The Unit Test Framework opted to avoid explicit
names in fixture interface for setup
and teardown
methods, since
it is considered most natural in C++ for tasks similar to RAII and coincides
with the pure C++ solution discussed above.
This model is expected from fixtures used with BOOST_FIXTURE_TEST_CASE
and BOOST_FIXTURE_TEST_SUITE
.
Caution | |
---|---|
The above interface prevents you from reporting errors in the |
In addition to BOOST_FIXTURE_TEST_CASE
and BOOST_FIXTURE_TEST_SUITE
the
Unit Test Framework allows to associate fixture with
test unit using the decorator fixture
. This decorator supports
additional models for declaring the setup
and teardown
:
a fixture defined according to the extended fixture class model, which allows for the fixture constructor to takes one argument. For example:
struct Fx { std::string s; Fx(std::string s = "") : s(s) { BOOST_TEST_MESSAGE("set up " << s); } ~Fx() { BOOST_TEST_MESSAGE("tear down " << s); } };
a fixture defined as a pair of free functions for the setup
and teardown
(latter optional)
void setup() { BOOST_TEST_MESSAGE("set up"); } void teardown() { BOOST_TEST_MESSAGE("tear down"); }
For complete example of test module which uses these models please check
decorator fixture
.