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 it to be implemented in a separate reusable unit.

With introduction of eXtreme Programming (XP), the testing style, that require test setup/cleanup repetition, has become even 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 we'd like for a test module author to be able to define variables used in fixtures on the stack and, at the same time, to refer to them directly in a 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. 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:

The Unit Test Framework lets you define a fixture according to several generic interfaces, and thus helps you with following tasks: