Running Tests (old): Difference between revisions

From STRIDE Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 7: Line 7:
=== Host ===
=== Host ===
* [[Stride Host Tools]] installed on the host computer
* [[Stride Host Tools]] installed on the host computer
* Host transport configured (see below)


=== Target ===
=== Target ===
Line 14: Line 13:
* Target built with STRIDE library built in and one or more test cases
* Target built with STRIDE library built in and one or more test cases
* Target app running <ref>If target is multi-process, both the target and the STRIDE I/O daemon process must be started.</ref>
* Target app running <ref>If target is multi-process, both the target and the STRIDE I/O daemon process must be started.</ref>
== Host Transport Configuration ==
Host transport configuration is a one-time setup the comprises editing the <tt>transport.cfg</tt> file to reflect your target communication setup.
If you are using TCP/IP as your communcation channel, this configuration is typically only a matter of specifying your tareget's IP address (or DNS name) as the sockets DeviceAddress.
For configuration details, see [[Transport Configuration File]].


=== Verifying Transport Settings ===
=== Verifying Transport Settings ===
You can quickly verify your transport settings by running the [[Connect.pl]] script. (Installed to <tt>C:\STRIDE\Scripts\Connect.pl</tt>) (Your target must be running in order for the connection to succeed.)
You can quickly verify your transport settings by running


== Running Your Tests ==
== Running Your Tests ==
Line 30: Line 22:
Command line options allow you to tailor the the script's operation, but at a minimum:
Command line options allow you to tailor the the script's operation, but at a minimum:


* The script must be able to read the STRIDE database (.sidb) file that corresponds to the target build
* The stride executable must be able to read the STRIDE database (.sidb) file that corresponds to the target build
* The script uses the transport configuration settings in transport.cfg to establish communication with the target


By default, tests are run in the order in which their corresponding SCL pragmas were seen by the [[s2scompile|STRIDE compiler]] (This can be overridden; see below.)
By default, tests are run in the order in which their corresponding SCL pragmas were seen by the [[s2scompile|STRIDE compiler]] (This can be overridden; see below.)
Line 38: Line 29:
Commonly useful flags for [[TestUnitRun.pl]] include -v and -u. (See the link for complete information). For example:
Commonly useful flags for [[TestUnitRun.pl]] include -v and -u. (See the link for complete information). For example:


==== Pre-Flight Testing ====
==== Desktop Interactive Testing ====
Useful for 'pre-flight' desktop testing, the following command line runs the target tests then automatically launches the local HTML report in your browser.
Useful for 'pre-flight' desktop testing as well as target debugging, the following command line runs the target tests without publishing results to [[STRIDE Test Space]].


  TestUnitRun.pl -d stride.db -v
  stride -r --database "/my/path/stride.sidb" --device TCP:localhost:8000


==== Publication to Test Space ====
==== Testing with Publication to Test Space ====
This example will run the target tests and then publish the results to [[STRIDE Test Space]] according to the configuration specified in your [[Test Spaces Configuration File]].
This example will run the target tests and then publish the results to [[STRIDE Test Space]] according to the configuration specified in your [[Test Spaces Configuration File]].



Revision as of 23:19, 27 May 2009

Overview

Target-based Test Units are controlled by a host computer, physically connected to the target via a configurable communication channel (TCP/IP or serial port). This article describes the

Prerequisites

In order to run target-based Test Units, the following prerequisites are required.

Host

Target

  • Target transport configured
    • TCP/IP over port 8000 is the default target transport. To apply other configurations, see Host Transport
  • Target built with STRIDE library built in and one or more test cases
  • Target app running [1]

Verifying Transport Settings

You can quickly verify your transport settings by running

Running Your Tests

Tests are executed on the target by running the program stride.exe on the host computer.

Command line options allow you to tailor the the script's operation, but at a minimum:

  • The stride executable must be able to read the STRIDE database (.sidb) file that corresponds to the target build

By default, tests are run in the order in which their corresponding SCL pragmas were seen by the STRIDE compiler (This can be overridden; see below.)

Examples

Commonly useful flags for TestUnitRun.pl include -v and -u. (See the link for complete information). For example:

Desktop Interactive Testing

Useful for 'pre-flight' desktop testing as well as target debugging, the following command line runs the target tests without publishing results to STRIDE Test Space.

stride -r --database "/my/path/stride.sidb" --device TCP:localhost:8000

Testing with Publication to Test Space

This example will run the target tests and then publish the results to STRIDE Test Space according to the configuration specified in your Test Spaces Configuration File.

TestUnitRun.pl -d stride.db -u -n="My Test Run"


Specifying Tests to Run

By default all tests are run in the order in which their corresponding SCL pragmas were seen by the STRIDE compiler. This is typically what you want, but you may also specify which test suites to run and in what order they are to be run.[2]

  • Specify test(s) to run and their order on the TestUnitRun.pl command line (using -r)
  • Specify test(s) to run and their order by means of an Order File

Notes

  1. If target is multi-process, both the target and the STRIDE I/O daemon process must be started.
  2. A test suite here is the grouping of tests by SCL pragma; this corresponds to either:
    • a test class
      • #pragma scl_test_class()
    • a set of free functions, or
      • #pragma scl_test_flist()
    • a C-based class)
      • #pragma scl_test_cclass()