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:

preconditions

particular states of tested units

necessary cleanup procedures

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:

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:

We need to add a fixture declaration statement into each test case manually.

Objects defined in fixture are references with <fixture-instance-name>
prefix.

There is no place to execute a global fixture, which
performs global setup/cleanup procedures before
and after testing.

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

define shared setup/teardown procedures for a single or group of test
cases

define setup/teardown procedures which are performed once per test suite

define global setup/teardown procedures which are performed once per
test module