Test Class Sample

Introduction

These examples cover the use of Test Classes to create logical groupings of test cases. For unit testing, one test class is typically created for each class under test, although more complicated scenarios often justify other arrangements. Test Classes require a c++ compiler.

NOTE: each of the example test classes is grouped in namespace corresponding to its category (e.g. Basic or Runtime Services). This is something shown for organizational purposes only -- it is not a general requirement that test classes be placed into namespaces.

Tests Description

Basic

These examples cover the simplest, easiest way to code a STRIDE test class. These examples use simple POD return types to indicate status.

Basic::Simple

This example demonstrates passing and failing tests using the four primary integer types (int, bool, short, and char) 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::Exceptions

This example demonstrates exceptions thrown from a test method are caught by the intercept module and noted in the results. Any exception that is caught by the harness is assumed to indicate failure. If you want to write tests for expected exceptions, consider using our exception macros

Basic::Parameterized

This example demonstrates how to pass arguments to the constructor of your test unit. 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 the Runtime Test Services API (as declared in srtest.h).

RuntimeServices::Simple

This example demonstrates how to use srTestCaseSetStatus to set status, srTestCaseAddComment to add a comment, and srTEST_ADD_COMMENT_WITH_LOCATION to add a comment that automatically includes line and file information.

RuntimeServices::Dynamic

This example demonstrates how to use srTestSuiteAddSuite, srTestSuiteAddCase, srTestSuiteAddAnnotation, and srTestAnnotationAddComment for dynamic suite, test, 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 srTestCaseAddComment.

srTest

These examples show to how to use the stride::srTest base class for your test classes. When you publicly inherit from srTest, you get access to default testCase and testSuite members and their associated methods.

srTest::Simple

This example demonstrates the use of testCase.setStatus to set the status for test cases.

srTest::Dynamic

This example demonstrates how to use testSuite.AddSuite, testSuite.AddTest, testSuite.AddAnnotation, and testSuite.AddAnnotation.AddComment for dynamic suite, test case, and annotation creation within the context of one test method.

Run Tests

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

Test Class tests:

stride --device="TCP:localhost:8000" --database="../out/TestApp.sidb" --run="s2_testclass::Basic::Exceptions; s2_testclass::Basic::Fixtures;  s2_testclass::Basic::Parameterized; s2_testclass::Basic::Simple" --output=TestClass.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 shows the techniques available for packaging and writing test units using classes. If you have a C++ capable compiler, we recommend that you use test classes to package your unit tests, even if your APIs under test are C only. Review the source code in the directory and follow the sample description.

The following are some test observations:

• all of these example classes have been put into one or more namespaces. This is just for organization purposes, mainly to avoid name collisions when built along with lots of other test classes. Your test classes are not required to be in namespaces, but it can be helpful in avoiding collisions as the number of tests in your system grows.
• we've documented our test classes and methods using doxygen style comments. This documentation is automatically extracted by our tools and added to the results report - more information about this feature is here
• you can optionally write test classes that inherit from a base class that we've defined (stride::srTest). We recommend you start by writing your classes this way so that your classes will inherit some methods and members that make some custom reporting tasks simpler.
• exceptions are generally handled by the STRIDE unit test harness, but can be disabled if your compiler does not support them (see s2_testclass_basic_exceptions_tests.h/cpp).
• parameterized tests are supported by test classes as well. In these tests, simple constructor arguments can be passed during execution and are available at runtime to the test unit. The STRIDE infrastructure handles the passing of the arguments to the device and the construction of the test class with these arguments. Parameterization of test classes can be a powerful way to expand your test coverage with data driven test scenarios (varying the input to a single test class).