Tool strategy

As indicated in the Introduction, cfix implements a separation between test code, which is provided in form of a test module, and the test runner, which is provided by cfix. This separation is similar to NUnit and JUnit, but differs significantly from the approach chosen by CUnit and CppUnit.

All test cases and fixtures are compiled and linked into a single DLL, the test module. The test runner, named cfix32.exe (or cfix64.exe for AMD64 platforms), can now be used to run all or a selection of test fixtures. The way cfix implements this introspection of a test module is to rely on the features of the PE file format used by Windows. By inspecting the export directory of the PE file, all fixtures defined in a test module can be identified. Depending on user input, cfix can then selectively run these fixtures. This approach is similar to WinUnit, although the exact implementation differs.

Figure 2.1. User mode testing: basic architecture

For kernel mode code, the architecture looks slightly different. The tests are compiled into a driver rather than into a DLL. The driver is very lightweight and, besides the tests, contains only very little cfix-provided code (basically, just a DriverEntry implementation).

When cfix32 or cfix64 is requested to run a kernel mode tests, it will load the Reflector, a driver that contains the kernel mode fraction of the testing framework. Relaying control operation and output through the reflector, the kernel mode unit tests can be run.

Figure 2.2. Kernel mode testing: basic architecture

All these additional steps are performed without additional user intervention -- the drivers are installed, loaded and stopped automatically. From a user perspective, running a kernel mode tests feels just like running a user mode test.