Skip to content

Parametrized Tests: Implementation Documentation

the-real-orca edited this page Jun 8, 2015 · 2 revisions

To add parametrized tests to cpputest two tasks have to be solved:

  • parametrize the test templates (= mixin tests)
  • Add the test templates to one or more test groups

Parametrize test templates

  • First of all, there needs to be a parameter structure for the test templates (= mixin tests).
  • This parameters are used within the mixin test implementation, and set when adding the mixin tests to an actual test group.
  • All mixin tests within a mixin group share the same parameter set. -> the parameter set is defined for a mixin group
  • A mixin group can have setup() and teardown() functions (just like an ordinary test group). Within the setup() and teardown() functions the parameters can be used for initializing the test environment.

The parameter structure is defined with the MIXIN_PARAMS(mixinGroup) macro. And needs to be visible in the scope of the mixin test implementation AND the actual test groups the mixins are applied to. The params struct is defined as member variable of the mixin group class (see MIXIN_GROUP macro). Since all mixin tests are derived from this class the params are available for all tests within this mixin group.

Setting the params for a specific test is done by the prepareScope() function of the injected mixin wrapper test (see MIXIN_APPLY macro). The mixin wrapper test runs in the scope of a normal test group (so the setup() of the test group applies also to all mixins injected by this wrapper) and prepares the environment for the injected mixin test (setting the params). To do this, the mixin wrapper gets a pointer to the params member variable of the executed mixin test.

Adding mixins to test groups

The second task is to add a generic number of mixin tests to a test group.

One of the design goals was to separate the mixin test definition from the normal test definition, and also avoid including mixin tests as headers to actual test files (this would lead to multiple definition errors). So the mixin tests and mixin test groups have to be stored in somewhere -> the mixin registry.

The mixin wrapper test base class (MixInInjectionUTest) acts as stand-in-double for the mixin tests. From normal test registry point of view the mixin wrapper test is a normal test within the current test group. Internally it prepares and executed the first mixin test of the given mixin group (by searching the mixin registry). The important trick is, that the pointer to the next test is bent to itself, as long as there are mixin tests to be executed. Only when all mixin tests of the mixin group are executed, the original next test pointer is restored.

System Architecture

normal tests

mixin tests

mixin apply