> The Unit Test Framework > User's guide > Fixtures > |
In general terms a test fixture or test context is the collection of one or more of the following items, required to perform the test:
Though these tasks are encountered in many if not all test cases, what makes a test fixture different is repetition. Where a normal test case implementation does all preparatory and cleanup work itself, a test fixture allows this to be implemented in a separate reusable unit.
With introduction of extreme programming (XP), the testing style, that require test setup/cleanup repetition, is becoming more and more popular. Single XP adopted test modules may contain hundreds of single assertion test cases, many requiring very similar test setup/cleanup. This is the problem that the test fixture is designed to solve.
In practice a test fixture usually is a combination of setup and teardown functions, associated with test case. The former serves the purposes of test setup; the later is dedicated to the cleanup tasks. Ideally it's preferable that a test module author is able to define variables used in fixtures on the stack and the same time is able to refer to them directly in test case.
It's important to understand that C++ provides a way to implement a straightforward test fixture solution that almost satisfies our requirements without any extra support from the test framework. This may explain why test fixtures support was introduced in the UTF somewhat late in its life cycle. Here is how simple test module with such a fixture may look like:
struct MyFixture { MyFixture() { i = new int; *i = 0 } ~ MyFixture() { delete i; } int* i; }; BOOST_AUTO_TEST_CASE( test_case1 ) { MyFixture f; // do something involving f.i } BOOST_AUTO_TEST_CASE( test_case2 ) { MyFixture f; // do something involving f.i }
This is a generic solution that can be used to implement any kind of shared setup or cleanup procedure. Still there are several more or less minor practical issues with this pure C++ based fixtures solution:
While there is little the UTF can do to address these issues for manually registered test units, it's possible to resolve them for test units that are automatically registered. To do this the UTF defines a generic fixture model - fixed interfaces that both setup and teardown fixture functions should comply to. Based on the generic fixture model, the UTF presents solution for the following tasks: