Unit testing helps us to find bugs "in the small"; little implementation details that we got wrong while we were building a function, a method or a class. When we test each class as an isolated unit, we can miss errors in the way two classes interact or in the way a whole ensemble of classes cooperate in an integrated system.

An acceptance test is an automated test that exercises our system as an integrated whole and not as a collection of isolated units. In a unit test, we decouple ourselves from the execution environment in order to test a piece of code in isolation. In an acceptance test, we run the whole system and provide controlled inputs to the system. This may consist of prepared input data files, prepared input databases and so-on.

Using these two forms of automated testing, we can use them as a vise to squeeze bugs between the two forms of automated tests. Unit tests push from below and acceptance tests push from above.

While the facilities in Boost.Test can be used to create an automated acceptance test, the tools are fairly low-level for the kinds of high-level criteria that an acceptance test would use. Acceptance tests are usually defined by the product owner or customer and will describe acceptance criteria in the language closest to the problem domain and farthest away from the details of the implementation.

A better approach for automated acceptance tests would be a tool such as FitNesse that is designed for automated acceptance testing.