主要内容

Optimize xUnit Test Executables for Embedded Targets

To run xUnit tests on an embedded target, you generate the test executable by cross-compiling your tests and source files for the embedded target. By default, the test executable generates results in a human-readable text format. Because embedded devices often have memory constraints, you can generate a smaller test executable that is capable of running the tests and generating the results in a machine-readable format.

This topic shows how you can create smaller xunit test executables for embedded targets and how to review results that you obtain from the smaller test executables.

Create Smaller Test Executables

You can create smaller test executables for embedded systems by defining one of these two macros:

  • PST_EMBEDDED_MODE — When you define this macro, the test executable is smaller and generates machine-readable output instead of human-readable output. If you use a gcc cross-compiler, you can define the macro PST_EMBEDDED_MODE by appending this -D flag to your build command:

    -D PST_EMBEDDED_MODE=1

    Alternatively, you can set the macro to 1 in a test configuration header file:

    #define PST_EMBEDDED_MODE 1
    For more information on test configuration headers, see Configuration Macros in Polyspace Test API for C/C++ Code.

    To reduce the size of the test executable, some functionalities are not available for this macro. For instance, the executable ignores any command you pass to it at the command line. You cannot change which tests to run or select the output format at the command line.

  • PST_COMPACT_EMBEDDED_MODE — When you define this macro, the test executable is compressed further. If you use a gcc cross-compiler, you can define the macro PST_COMPACT_EMBEDDED_MODE by appending this -D flag to your build command:

    -D PST_COMPACT_EMBEDDED_MODE=1
    Note that setting PST_COMPACT_EMBEDDED_MODE to 1 sets the macro PST_EMBEDDED_MODE to 1 besides performing other optimizations.

    Alternatively, you can set the macro to 1 in a test configuration header file:

    #define PST_COMPACT_EMBEDDED_MODE 1
    For more information on test configuration headers, see Configuration Macros in Polyspace Test API for C/C++ Code.

    To reduce the size of the test executable, some functionalities are not available for this macro:

    • The test executable ignores any command you pass to it at the command line. For instance, you cannot change which tests to run or select the output format at the command line.

    • The test executable reports less information about the tests.

    • The test executable does not calculate the time required to run the xUnit tests.

Review Test Result

The optimized test executables do not generate human-readable text output. To review the test results, you must obtain a file with the .mrf extension and then convert the file into a report or a file with the .pstestr extension.

  1. Run the test executable in the embedded device and store the output in an .mrf file. For instance, if the test executable is named testRunner.exe, at the command line, enter:

    testRunner.exe  > out.mrf
    This step generates the test results and stores the result in the file out.mrf.

    If your embedded device does not support running commands at a command-line interface, collect the binary output of the test executable and then save the output as an .mrf file in the host computer.

  2. At the host device, convert the .mrf results into .pstestr results by using the polyspace-test -convert command:

    polyspace-test -convert -results-dir  resultsDir out.mrf
    The folder resultsDir contains the converted .pstestr file. If you have access to the Polyspace® Platform user interface, you open this file and review the test results in the user interface.

  3. To make a human-readable HTML report from the .pstestr file, at the command line, enter:

    polyspace-test -report HTML -report-dir reportDir resultsDir
    The folder reportDir contains the HTML report. The report summarizes the pass or fail status of your tests. Because the test executable is optimized, the report might not contain the details that are available when the executable is not optimized.

See Also

|

Topics