Test Intro Sample

Introduction

This sample comprises several example Test Units and is intended as a starting point for getting familiar with the STRIDE Test Unit approach in a C-only environment. (For an overview from a C++ perspective, please see Test Intro Cpp Sample.) The sample is short and covers a number of core features in the unit test framework.

Furthermore, since this example has no external dependencies, it is a viable candidate for use as an initial set of tests integrated with your target device. In this capacity, this sample can be used to quickly get a feel for the end-to-end integration and execution of STRIDE Test Units on your device.

Tests Description

s2_testintro_cclass

This example covers the following topics:

• test_cclass test units
• fixturing
• pass/fail macros
• Note Macros

This demonstrates the declaration and use of a C-class test unit -- a structure with function pointer members and optional member data. The test unit contains the following test cases:

testBasics_PASS

calls a simple FUT (function under test) and uses srEXPECT macros to validate the return value. All assertions pass for this test case.

testBasics_FAIL

calls the same FUT and uses srEXPECT macros to validate the return value. All assertions fail for this test case.

This example also demonstrates the use of fixturing functions that are automatically called by the STRIDE framework to surround each test case call with setup/teardown functionality. Here, the fixturing simply writes a srNOTE message, which can be seen in the test results report.

As with all STRIDE test units, the test cases are executed in the order that they appear in the "C Class".

s2_testintro_flist

This example covers the following topics:

• test_flist test units
• pass/fail macros
• asynchronous code validation

This example demonstrates the declaration and use of a function list test unit (flist) which is made up of individual C linkage test functions. Flists are the simplest kind of test unit that can be created for C-only compilation units, but they lack some of the capabilities of CClass test units (such as member data and the ability to use non-extern functions as tests).

This test unit contains three test cases: the first two are identical to the CClass example above. The third test - testBasics_Asyn_PASS - demonstrates a technique for simple asynchronous event testing by creating a timer using the PAL API and validating that the registered callback was invoked.

s2_testintro_testdoubles

This example covers the following topics:

• test double
• mock functions
• fake functions
• pass/fail macros

This example demonstrates the use of STRIDE's test double technique to implement mocks and fakes. The function being tested for these examples is s2CopyString (in s2_testintro_source.c) and depends on s2MoveString - the target of our doubling. The example includes the following test cases:

testDoubles_Normal

calls s2CopyString function as part of its testing. s2CopyString, as part of its implementation, calls s2MoveString. This test case does not do anything special - there is no doubling.

testDoubles_Mock

does a dynamic replacement of the implementation of the original s2MoveString with a different mock implementation named s2MoveString_Mock. The test calls s2CopyString as before, but within s2CopyString the call is routed to our mock implementation. s2MoveString_Mock verifies that the input string passed to s2CopyString is correctly propagated to its call to s2MoveString.

testDoubles_Fake

like the previous test, does a dynamic replacement of s2CopyString's call to s2MoveString, this time to a fake implementation named s2MoveString_Fake. In this case, s2MoveString_Fake forces an error condition. The testDoubles_Fake test verifies that the error is handled as expected by s2CopySting.

s2_testintro_testpoints

This example covers the following topics:

• test points
• event verification
• state verification
• asynchronous code validation

The example includes the following test cases:

testPoints_Event

uses STRIDE test points to verify the state of a counter implemented in the function s2RegCount. The counter is expected to reset to zero after a specific number of function calls. By firing a test point upon reset, the counter can communicate the reset occurrence to the testPoints_Event test.

testPoints_States

uses STRIDE test points to verify the operation of a state machine.

testPoints_Asyn

uses STRIDE test points to verify the receipt of an asynchronous event.

s2_testintro_parameters

This example shows how to reuse test logic across multiple tests. By creating a parameterized test unit we can provide parameters at run time to customize the test unit's member test cases. The s2_testintro_parameters test unit verifies the operation of two string functions. The test unit is coded to accept the following parameters:

• a string
• an integer indicating the string length
• an integer indicating the number of spaces in the string

The test unit (implemented as a C-Class) receives these parameters in its init function and stores these values in member variables which are subsequently used by the member test cases.

The example includes the following test cases:

parameters_StringLength

Verifies that the calculated length of a string matches the expected value

parameters_NumberOfSpaces

Verifies that the calculated number of spaces in a string matches the expected value

A common use of this type of test is to call it repeatedly with different values in order to provide coverage or to exercise boundary conditions of the function(s) under test. For example, the following might submitted as --run arguments to stride. (These would typically be put into an options file and submitted to the stride command line using the --options_file option.)

--run "/{s2_testintro_parameters(\" \", 1, 1)}"
--run "/{s2_testintro_parameters(\"m\", 1, 0)}"
--run "/{s2_testintro_parameters(\"my \", 2, 1)}"
--run "/{s2_testintro_parameters(\"my string\", 9, 1)}"