Training Tests in C/C++

Background

The STRIDE Framework provides support for implementation of tests in the native C/C++ of the device under test. Once written, these tests are compiled using the device toolchain and are harnessed, via the STRIDE Intercept Module into one or more applications under test on the device. These tests have the unique advantage of executing in real-time on the device itself, allowing the tests to validate actual device conditions during test.

Please review the following reference articles before proceeding:

• Overview
• Test Units
• Test Macros
• Expectation Testing

Why would I want to write tests in native code ?

Here are some of the scenarios for which on-target test harnessing is particularly advantageous:

• direct API testing. If you want to validate native APIs by driving the APIs directly, native code is the simplest way to do so. STRIDE provides convenient assertion macros to validate your variable states. API testing can also be combined with native expectation tests (using Test Point instrumentation) to provide deeper validation of expected behavior of the units under test.
• unit testing of C objects or C++ classes. The STRIDE native tests execute in the same context as the rest of your code, so it's possible to fully unit test any objects that can be created in your actual application code.
• validation logic that requires sensitive timing thresholds. Sometimes it's only possible to validate tight timing scenarios on target.
• high-volume data processing scenarios. In some cases, the volume of data being processed and validated for a particular test scenario is to large to be easily handled by an off-target harness. In that case, native test units provide a convenient way to write tests that validate that data without shipping the data off-target during testing.

In addition to these, you might simply prefer to write your test logic in C or C++ (as opposed to perl on the host). If that's the case, we don't discourage you from using a toolset that your more comfortable with - particularly if it enables you to start writing tests without a new language learning curve.

Are there any disadvantages ?

Sure. Most of the disadvantages of native on-target tests involve the device build process. If your device build is particularly slow (on the order of hours or days), then adding and running new tests can become a tedious waiting game. Testing is always well served by shorter build cycles, and on target tests are particularly sensitive to this.

In some cases, the additional code space requirements of native tests is a concern, but this concern is also mitigated by ever-increasing device storage capacities. On platforms that support multiple processes (e.g. embedded linux or WinMobile), it's possible to bundle tests into a separate test process, further mitigating the code space concern by isolating the test code in it's own application.

Samples

For this training, we will be using some of the samples provided in the C/C++_Samples. For any sample that we don't cover here explicitly, feel free to explore the sample yourself.

TestCClass

not sure about this one...