Manual

On this page: Recipe - Selectors - Categories

Recipe

A key concept of csUnit is the recipe. A recipe is basically almost like a project in your favorite IDE. Basically a recipe consists of one or more test assemblies, that is assemblies that contain tests.

Furthermore the recipe can contain additional information, e.g. about the categories to be included/excluded in a test run.

The csUnit command line is able to read the recipe and execute the tests according to the information in the recipe. From a different perspective the csUnitRunner (the native application) becomes the editor for recipes.

Selectors

csUnit uses the concept of selectors to determine the tests to run within a recipe. Remember that a recipe consists of one or more test assemblies. Each of them containing zero or more tests.

A selector is basically a piece of logic that determines whether or not a test is included in a test run. An example could be a category selector. It includes/excludes tests based on the selected categories and the categories assigned to the test.

Currently csUnit supports the category selector as the only selector type. We have however ideas/plans for additional selectors.

Categories

csUnit supports categorization of tests. Basically this means you and assign categories to tests and test fixtures, and then use that categorization for instance for selecting tests. If you don't like the feature you can safely ignore it and still use csUnit. This is one of the design principles we try to follow wherever possible.

If you assign one or more category to a test or a test fixture, please be aware of the following rules:

1. If a test has no categories assigned then the default setup/teardown method will be executed. The default setup/teardown method is the one that has no categories assigned to it. If no such default setup/teardown method exists, no setup/teardown will get executed.
2. If a test has one or more categories assigned then the setup/teardown for that category or those categories will be executed. If a categorized setup/teardown method doesn't exists, the default method will be executed if it exists.
3. If more than one default setup/teardown method exists, of if more than one categorized setup/teardown method exists, this is considered to be an error and the test(s) will fail. This test is performed per test fixture. The latter means that in a hierarchy of test fixtures a base class can have a setup/teardown method, and a derived class can have a setup/teardown method, either default or categorized.
4. If a test fixture is derived from a base class that is itself a test fixture, setup/teardown methods from the base class will not be considered for the derived test fixture. Also, even if a method in the base class is declared virtual and marked as SetUp/TearDown, it will not be considered by csUnit's runtime. If you need to execute setup/teardown code in the base class, you need to call the base class method from your code, e.g. base.MySpecialSetupMethod().