Test assets overview

HCL OneTest™ Embedded several types of assets, which each describe different levels of the test environment.

These test assets include the following items:

  • Test cases contain the verification actions for source code functions.
  • Stubs are dummy components that allow you isolate the components under test or to replace components that do not exist.
  • Test harnesses contain test cases and the associated source files and stubs required to run the test.
  • Test suites contain multiple test harnesses that are run sequentially.

Test cases

A test case applies to a function and describes the checks that are performed against the variables contained in the component under test.

For each variable, array, or struct, you can specify an initialization value and an expected value. These values can be finite values, sets, or ranges, with multiple comparison types. When the test case is run, each check compares the expected value to the actual value and generates a Passed or Failed verdict.

The data used to specify initialization and expected values can be provided by native code, function calls, data pools or linked to a data dictionary. A data pool is a table, typically imported from a spreadsheet, containing multiple associated data sets. A data dictionary is a list of initialization and expected values for each variable type that can be reused by multiple test cases in the project.

You create a test case by selecting a function in the project explorer or the call graph. The test case is generated with the variables that are visible from outside the function. For each variable, a default check is added to the test case. You can use the test case editor to specify the initialization and expected values of each variable check.

Stubs

A stub is a dummy software component designed to replace a component that the component under test relies on, but cannot use in the test because it is not practical or available. A stub simulates the response of the stubbed component. Stubs can also be used to isolate the behavior of the component under test to provide more reliable test results or to simulate specific input values that cannot be practically simulated with the actual component. Stubs can be used in the following roles:
  • Retrieving and storing input values to stubbed functions from a function under test.
  • Assigning output values from the stubbed functions to a function under test.

Stubs generate passed or failed results based on the number of times that they are called.

You create a stub by selecting a function in the project explorer or the call graph. The stub is generated with the same interface as the stubbed function.

You can use the stub editor to specify the behavior of the stubbed function. You can also add additional blocks of code and conditions to structure the behavior of the test case.

Test configurations

The test configuration is an instance of a target deployment port (TDP) and its associated configuration settings. Configuration settings are the particular properties assigned to each test harness for a given test configuration.

For example, you can create a test configuration for each compiler involved in your project. If you are developing for an embedded platform, you can have one test configuration for native development on your Unix or Windows™ development platform and another test configuration for running and testing the same code on the target platform.

You can set up several test configurations based on the same TDP, but with different libraries, compilers or settings. The configuration settings allow you to customize test and runtime analysis options for each test asset in the project. You can reach the configuration settings for each test asset by right-clicking any node in the project explorer window and selecting Properties > C/C++ Build > Settings and Build TDP or Build Instru.

Test harnesses

The test harness contains all the test assets that are required to compile and run the test. These test assets include:
  • Test cases
  • Stubs
  • Required source files, including:
    • Tested files: These are source files under test. The functions of these components are instrumented and integrated into the test harness.
    • Additional sources: These are dependency files that are added to test harness, but are not tested or instrumented. For example: resource files can be compiled inside a test harness by specifying them as additional files.
    • Linked files: These are source files that are linked with the test harness but are not tested or instrumented.
    • Libraries: These are libraries that are required for the link. For example: math libraries.
The test harness can also contain header code and global declarations that are required to run the test and instantiates the parameters of the test case.

You can use the test harness editor to add and remove test assets from the test harness and to graphically arrange the order in which the test cases are run. You can also add additional blocks of code and conditions to structure the behavior of the test harness.

To run a test harness, it must be associated with a test configuration. You can do this in a run configuration or in a test suite.

Test suites

A test suite contains multiple test harnesses that are run sequentially to provide global results for a project.

In the test suite, each test harness is associated with a test configuration (a TDP with associated configuration settings) and can be run a second time with another test configuration to provide comparison results. For example, this can be useful for certification purposes.