Test CClass Sample

Introduction

The Test CClass test unit provides a test unit based on a C struct that is acting like a class object for the purpose of test unit containment. The Test CClass functionality is most useful for target environments that do not support C++. However, the Test CClass functionality may be used in C++ environments as well. (If you are using C++, please see the Test Class Sample.)

Tests Description

Basic

These examples cover the simplest, easiest way to code a STRIDE test CClass. These examples use simple POD return types to indicate status and do not annotate the tests with any rich information (such as comments).

basic_simple

This example demonstrates passing and failing tests using the four primary integer (int, short, and char) types that infer status from.

basic_fixtures

This example demonstrates how to use setup and teardown fixtures. The setup and teardown methods are called immediately before and after the execution of each test method, respectively.

basic_parameterized

This example demonstrates how to pass arguments to the initializer of your test CClass. This is something that is useful when you want to run the same test scenario with different sets of input data, for instance, as described by this pattern.

Runtime Services

These examples cover basic usage of our Runtime Test Services API (as declared in srtest.h).

runtimeservices_simple

This example demonstrates how to use srTestCaseSetStatus to set status and srTestCaseAddAnnotation to add a comment.

runtimeservices_dynamic

This example demonstrates how to use srTestSuiteAddCase, srTestCaseAddAnnotation, and srTestAnnotationAddComment for dynamic suite, test case, and annotation creation in the context of a single test method.

runtimeservices_override

This example demonstrates how to use srTestCaseSetStatus to override the status that would otherwise be inferred from the return value.

runtimeservices_varcomment

This example demonstrates the use of printf style format strings with srTestCaseAddAnnotation.

Run Tests

Now launch the test app (if you have not already) and execute the runner with the following commands:

Test C Class tests:

stride --device="TCP:localhost:8000" --database="../out/TestApp.sidb" --run="s2_testcclass_basic_fixtures; s2_testcclass_basic_parameterized(\"mystring\", 8); s2_testcclass_basic_simple" --output=CClass.xml

Note the command will produce distinct result files for the run (per the --output command above). Please use the result file to peruse the results by opening each in your browser.

Observations

This sample demonstrates a more sophisticated (and complicated) packaging technique for systems that support C compilation only. Test C Classes are defined by a structure of function pointers (which may also include data) and an initialization function. Review the source code in the directory and follow the sample description.

The following are some test observations:

• the scl_test_cclass pragma requires a structure of function pointers as well as an initialization function that is called prior to running the tests. The initialization function must take the c class structure pointer as it's first argument and it will assign values to all the function pointer elements as well as perform any other initialization tasks. The pragma also accepts an optional deinitialization function that will be called after test execution (if provided).
• we've provided documentation using doxygen formatting for these samples. Because the test functions themselves are bound at runtime, the test documentation must be associated with the function pointer elements in the structure - read more here.
• parameterized tests are also supported by test c classes. Arguments to the initialization function that follow the structure pointer argument are considered constructor arguments and can be passed when running the test.
• because the test methods are assigned to the structure members at runtime, it's possible (and recommended) to use statically scoped functions, so as not to pollute the global function space with test functions. That said, you are free to use any functions with matching signatures and linkage, regardless of scope.