Test Intro Cpp Sample

Introduction

These examples provide an overview of STRIDE features and techniques used in a C++ environment. (For an overview from a C perspective, please see Test Intro Sample.)

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

TestClass

This example shows a C++ class declared as a test unit and covers the following topics:

• test_class test units
• fixturing
• pass/fail macros

Pass

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

Fail

Calls a simple FUT (function under test) 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 an srLOG message, which can be seen in the test results report.

Note that the test cases are executed in the order in which they appear in the C++ class.

TestDoubles

This example covers the following topics:

• mock functions
• fake functions

This example demonstrates the use of STRIDE's test double technique to implement mocks and fakes. We are testing the object s2NetworkComm, which in turn depends on a "collaborator object" named s2Connection. s2NetworkComm gets the instace of s2Connection it will use by calling a factory function named s2CreateNetworkObj(). s2CreateNetworkObj() is declared as a double, which makes it possible to designate alternate implementations at runtime from our tests.

Normal

Simple case to demonstrate operation where no doubling is used. In this case, the s2NetworkComm instance created in the test will instantiate and use the true s2Connection object

Mock

Dynamically replaces s2NetworkComm's call to s2CreateNetworkObj() so that s2CreateCommObjectMock() is called instead, which results in an instance of the mock object s2ConnectionMock being instantiated and used in place of s2Connection.

Fake

Dynamically replaces s2NetworkComm's call to s2CreateNetworkObj() so that s2CreateCommObjectFake() is called instead, which results in an instance of the fake object s2ConnectionFake being instantiated and used in place of s2Connection.

TestPoints

This example covers the following topics:

• event verification

• state verification

• asynchronous code validation

The example includes the following test cases:

Event

Uses STRIDE test points to verify the state of a counter implemented by the class s2Counter. The counter is expected to reset to zero after a specific number of increments. By firing a test point upon reset, the counter can communicate the reset occurrence to the Event test.

States

Uses STRIDE test points to verify the operation of a state machine implemented by the class s2StateMachine.

Async

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

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 constructor and stores these values in member variables which are subsequently used by the member test cases.

The example includes the following test cases:

StringLength

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

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 -O 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)}"