Running and Publishing the TestIntro Sample: Difference between revisions

From STRIDE Wiki
Jump to navigation Jump to search
Line 32: Line 32:
Note that the S2 diagnostic tests (which are also present in this TestApp) are not shown in the list of Test Units.
Note that the S2 diagnostic tests (which are also present in this TestApp) are not shown in the list of Test Units.


== Running Test Intro Samples ==
== Running Test Intro Samples and Publishing Results to Test Space ==


=== Running All Tests ===
=== Running All Tests ===
Line 61: Line 61:
Disconnecting from device...
Disconnecting from device...
Saving result file...
Saving result file...
Uploading to test space...
</pre>
</pre>



Revision as of 16:34, 1 September 2009

Building the TargetApp to Include Test Intro Sample

In this step, will will add a set of sample tests that provide an overview of STRIDE testing techniques. The Test Intro Sample tests are described in the linked article.

This step requires an installation of the STRIDE Samples package. If not installed, please see Package Installation for more information.

The SDK Makefile is set up so that all .c .cpp and .h files found in the directory SDK/Linux/sample_src (or, alternatively SDK\Windows\sample_src) are included in the compile and link of the testapp target.

Further--as a pre-compilation step--any .h files found in sample_src are submitted to the S2 compiler and subsequent Build Tools. This will result in

  • the detection of SCL Pragmas which declare Test Units in these .h files
  • the inclusion of metadata into the sidb file to describe these Test Units
  • the generation of test harnessing code to run the indicated Test Units and collect results

To begin, be sure that TestApp is not running, then copy the .c and .h files found in Samples/TestIntro to SDK/Linux/sample_src (or Windows equivalent). Then build the TestApp as described in previous evaluation steps.

Listing Test Units in the Database File

In this step, we will use stride to list the Test Units in the TestApp.sidb database.

Run stride as follows (or Windows equivalent):

stride --list --database=~/stride/SDK/Linux/out/TestApp.sidb

You should see output like this:

s2_testintro_cclass
s2_testintro_flist
s2_testintro_testdoubles
s2_testintro_testpoints

Note that the S2 diagnostic tests (which are also present in this TestApp) are not shown in the list of Test Units.

Running Test Intro Samples and Publishing Results to Test Space

Running All Tests

Here we will run all tests in the TestApp.sidb database.[1]

  1. Invoke TestApp in a target console as in earlier steps.
  2. Invoke stride as shown below and verify Summary results.
stride --database=~/stride/SDK/Linux/out/TestApp.sidb --device=TCP:localhost:8000
Loading database...
Connecting to device...
  runtime version: 4.1.01
Executing test units...
  s2_testintro_cclass
    > 1 passed, 1 failed, 0 in progress, 0 not in use.
  s2_testintro_flist
    > 2 passed, 1 failed, 0 in progress, 0 not in use.
  s2_testintro_testdoubles
    > 3 passed, 0 failed, 0 in progress, 0 not in use.
  s2_testintro_testpoints
    > 3 passed, 0 failed, 0 in progress, 0 not in use.
  ---------------------------------------------------------------------
  Summary: 9 passed, 2 failed, 0 in progress, 0 not in use.

Disconnecting from device...
Saving result file...
Uploading to test space...

Running a Subset of Tests

Here we will run only the Test Units named s2_testintro_cclass and s2_testintro_flist against TestApp.

stride -r "s2_testintro_cclass, s2_testintro_flist" --database=~/stride/SDK/Linux/out/TestApp.sidb --device=TCP:localhost:8000
Loading database...
Connecting to device...
  runtime version: 4.1.01
Executing test units...
  s2_testintro_cclass
    > 1 passed, 1 failed, 0 in progress, 0 not in use.
  s2_testintro_flist
    > 2 passed, 1 failed, 0 in progress, 0 not in use.
  ---------------------------------------------------------------------
  Summary: 3 passed, 2 failed, 0 in progress, 0 not in use.

Disconnecting from device...
Saving result file...
  1. Note that the S2 diagnostic tests are treated separately, and are not run unless the --diagnostics option is specified to stride.