Test Function List Sample

Introduction

Function Lists are abbreviated as flist in both pragmas (as in scl_test_flist) and documentation. The Test flist Samples pertain to test units that contain lists of functions to be executed. The Test FList functionality is intended as a simple grouping of test functions and are designed to be used with the C language (although it is not restricted from compilation in a C++ environment as well). Test FLists does not support more advanced usages patterns like private test data. If you need more advanced functionality, consider using Test Classes (C++) or Test C-Classes.

Tests Description

Basic

These examples cover the simplest, easiest way to code STRIDE scl_test_flist functionality. 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 primary integer (int, short, and char) types that infer status from.

basic_fixtures

This example shows 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.

Runtime Services

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

runtimeservices_simple

This example shows how to use srTestCaseSetStatus to set status and srTestCaseAddComment to add a comment.

runtimeservices_dynamic

This example shows 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 shows 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.

Run Tests

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

Test FList tests:

stride --device="TCP:localhost:8000" --database="../out/TestApp.sidb" --run="s2_testflist_basic_fixtures; s2_testflist_basic_simple" --output=FList.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 simpler packaging technique that is appropriate for systems that support C compilation only (no C++). FLists are simple a collection of functions that are called in sequence. There is no shared state or data, unless you arrange to use global data for this purpose. Review the source code in the directory and follow the sample description.

The following are some test observations:

• flist tests support setup/teardown fixturing, but not parameterization or exception handling.
• we've again provided documentation using doxygen formatting for these samples. However, because there is no storage-class entity with which the docs are associated in an FList, there are some restrictions to the documentation, which you can read about here.
• notice how the scl_test_flist pragma requires you to both create a name for the test unit (first argument) and explicitly list each test method that is part of the unit. This is one disadvantage of flist over a test class (the latter does not require explicit listing of each test since all conforming public methods are assumed to be test methods).