Test Units Overview

What are STRIDE Test Units?

STRIDE Test Units is a general term for xUnit-style test modules running within the STRIDE runtime framework. These tests--written in C and C++--are compiled and linked with your embedded software and run in-place on your target hardware. They are suitable for both developer unit testing as well as ongoing regression testing.

An external Test Runner is provided which controls the execution of the tests and publishes test results to the local filesystem and optionally to S2's Internet STRIDE Test Space.

Test Unit Features

In all cases, STRIDE Test Units provide the following capabilities typical of all xUnit-style testing frameworks:

• Specification of a test as a test method
• Aggregation of individual tests into test suites which form execution and reporting units
• Specification of expected results within test methods (typically by using one or more Test Macros)
• Test fixturing (optional setup and teardown)
• Automated execution
• Automated results report generation

Unique Test Unit Features

In addition, STRIDE Test Units offer these unique features:

Remote Execution

Execution and reporting controlled from a remote host, thus making the framework useful for on-target embedded system testing

Dynamic Test and Suite Generation

Test cases and suites can be created and manipulated at runtime

Test Doubles

Dynamic runtime function substitution to implement on-the-fly mocks, stubs, and doubles

Asynchronous Testing Framework

Support for testing of asynchronous activities occurring in multiple threads

Multiprocess Testing Framework

Support for testing across multiple processes running simultaneously on the target

Automatic Timing Data Collection

Automatic "time under test" collection

Automatic Results Publishing to Local Disk and Internet

Automatic publishing of test results to STRIDE Test Space

Test Unit Deployment

Individual Tests

Individual test are implemented as test functions or methods which follow a four-phase testing pattern:

1. Setting up a test fixture (optional)
2. Exercising the System Under Test (SUT)
3. Verifying that the expected outcome has occurred (typically using calls to Assertion or Expectation Macros)
4. Tearing down the test fixture (optional)

Test Units

Individual functions or methods, which typically implement a single test case are grouped into one or more Test Units which are executed as atomic entities.

Grouping of individual tests into a Test Unit can be accomplished in any of three ways:

• A Test Unit can be comprised of the member functions of a C++ class,
• A Test Unit can be comprised of a set of C functions,
• A Test Unit can be comprised of C functions pointed to by members of a C Struct

Deployment as C++ Classes

The required steps to get started with writing test units are as follows:

1. Write a test unit and capture it with one of the Test Units pragmas.
You may simply create a C++ class with a number of test methods and SCL capture it using scl_test_class pragma:

// testcpp.h

class Simple 
{
public:
    int test1() { return  0;} // PASS
    int test2() { return 23;} // FAIL <>0
    bool test3() { return true;} // PASS
    bool test4() { return false;} // FAIL
};

#ifdef _SCL
#pragma scl_test_class(Simple)
#endif

Deployment C Functions

Or, if you are writing in C, create a set of global functions and SCL capture them with scl_test_flist pragma (in more complicated scenarios when initialization is required scl_test_cclass pragma could be a better choice):

// testc.h

#ifdef __cplusplus
extern "C" {
#endif

int test1(void) 
{
    return 0; // PASS
}

int test2(void) 
{
    return 23; // FAIL <>0
}

#ifdef __cplusplus
}
#endif

#ifdef _SCL
#pragma scl_test_flist("Simple", test1, test2)
#endif

Deployment as C Classes

Or, if you are writing in C, create a set of global functions and SCL capture them with scl_test_flist pragma (in more complicated scenarios when initialization is required scl_test_cclass pragma could be a better choice):

// testc.h

#ifdef __cplusplus
extern "C" {
#endif

int test1(void) 
{
    return 0; // PASS
}

int test2(void) 
{
    return 23; // FAIL <>0
}

#ifdef __cplusplus
}
#endif

#ifdef _SCL
#pragma scl_test_flist("Simple", test1, test2)
#endif










2. Build and generate the IM code using STRIDE Build Tools:

> s2scompile --c++ testcpp.h
> s2scompile --c testc.h
> s2sbind --output=test.sidb testcpp.h.meta testc.h.meta
> s2sinstrument --im_name=test test.sidb

If using STRIDE Studio, create a new workspace (or open an existing one), add the above source files, adjust your compiler settings, build and generate the IM manually through the UI, or write custom scripts to automate the same sequence.

3. Build the generate IM code along with the rest of the source to create your application's binary.
4. Download your application to the Target and start it.
5. Execute your test units and publish results using the Test Unit Runner.

> perl testunitrun.pl -u -d test.sidb

If using STRIDE Studio, you can execute individual test units interactively by opening the user interface view corresponding to the test unit you would like to execute, then call it. Further more you may write a simple script to automate your test units execution and result publishing.

Requirements

Several variations on typical xUnit-style test units are supported. The additional supported features include:

• Test status can be set using STRIDE Runtime APIs or by specifying simple return types for test methods.
• Integral return types: 0 = PASS; <> 0 = FAIL
• C++ bool return type: true = PASS; false = FAIL
• void return type with no explict status setting is assumed PASS
• Test writers can create additional child suites and tests at runtime by using Runtime APIs.
• We do not rely on exceptions for reporting of status.
• One of the Test Unit pragmas must be applied.

The STRIDE test class framework has the following requirements of each test class:

• The test class must have a suitable default (no-argument) constructor.
• The test class must have one or more public methods suitable as test methods. Allowable test methods always take no arguments (void) and return either void, simple integer types (int, short, long or char) or bool. At this time, we do not allow typedef types or macros for the return values specification.
• The scl_test_class pragma must be applied to the class.

Simple example using return values for status

Using a Test Class

#include <srtest.h>
  
class Simple {
public:
    int tc_Int_ExpectPass() {return 0;}
    int tc_Int_ExpectFail() {return -1;}
    bool tc_Bool_ExpectPass() {return true;}
    bool tc_Bool_ExpectFail() {return false;}
};

#ifdef _SCL
#pragma scl_test_class(Simple)
#endif

Using a Test Function List

#include <srtest.h>
  
#ifdef __cplusplus
extern "C" {
#endif
  
int tf_Int_ExpectPass(void) {return 0;}
int tf_Int_ExpectFail(void) {return -1;}

#ifdef _SCL
#pragma scl_test_flist("Simple", tf_Int_ExpectPass, tf_Int_ExpectFail)
#endif
   
#ifdef __cplusplus
}
#endif

Simple example using runtime test service APIs

Using a Test Class

#include <srtest.h>
  
class RuntimeServices_basic {
public: 
  void tc_ExpectPass() 
  {
    srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should pass");
    srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0); 
  }
  void tc_ExpectFail() 
  {
    srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should fail");
    srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_FAIL, 0); 
  }
  void tc_ExpectInProgress() 
  {
    srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should be in progress");
  }
};

#ifdef _SCL
#pragma scl_test_class(RuntimeServices_basic)
#endif

Using a Test Function List

#include <srtest.h>
  
#ifdef __cplusplus
extern "C" {
#endif
  
void tf_ExpectPass(void) 
{
  srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should pass");
  srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0); 
}
void tf_ExpectFail(void) 
{
  srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should fail");
  srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_FAIL, 0); 
}
void tf_ExpectInProgress(void) 
{
  srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should be in progress");
}

#ifdef _SCL
#pragma scl_test_flist("RuntimeServices_basic", tf_ExpectPass, tf_ExpectFail, tf_ExpectInProgress)
#endif
 
#ifdef __cplusplus
}
#endif

Simple example using srTest base class

#include <srtest.h>
  
class MyTest : public stride::srTest {
public:
  void tc_ExpectPass() 
  {
    testCase.AddComment("this test should pass");
    testCase.SetStatus(srTEST_PASS, 0); 
  }
  void tc_ExpectFail() 
  {
    testCase.AddComment("this test should fail");
    testCase.SetStatus(srTEST_FAIL, 0); 
  }
  void tc_ExpectInProgress() 
  {
    testCase.AddComment("this test should be in progress");
  }
  int tc_ChangeMyName() 
  {
    testCase.AddComment("this test should have name = MyChangedName");
    testCase.SetName("MyChangedName");
    return 0;
  }
  int tc_ChangeMyDescription() 
  {
    testCase.AddComment("this test should have a description set");
    testCase.SetDescription("this is my new description");
    return 0;
  }
};

#ifdef _SCL
#pragma scl_test_class(MyTest)
#endif

Using Testpoints

Testpoints are covered in the article Using Testpoints.