STRIDE Runner

Overview

The stride executable (a.k.a. STRIDE Runner) runs script or native target-based tests from a host computer and optionally uploads results to STRIDE Test Space. The program also can be used to list the names of all Test Units and intercepted Functions that exist in a STRIDE database file.

The stride executable is available to run on Windows and on Linux x86.

Running Tests

You may specify either built-in diagnostics or user tests to be run.

The built-in diagnostics are useful to validate a new installation. See Running Diagnostics for details.

User tests comprise either sample tests provided by S2 Technologies or tests that you create.

Publishing Pre-Existing Test Reports

The stride executable may also be used to publish existing STRIDE test reports (xml files generated by stride.exe when tests are run).

For details click here.

Input

In order to run tests, you must provide the following information to stride.exe:

database file

This is the .sidb file that is created by the Build Tools during the target build process. This file contains meta-information used to run tests.

device parameters

This tells stride.exe how to connect to the target.

tests to run

A set of script tests or native target-based tests (Test Units) compiled in the database. You may also optionally specify named hierarchical suites in which to put the results of the tests you designate.

Default Behavior

By default, no tests are run. You need to explicitly list them using the --run option.

Test Unit Run Order

When explicitly specified, Tests are run in the order in which they are given on the command line.

It is possible to run all Test Units by explicitly specifing a wildcard (*). In that case they are run in alphabetical order.

Test Unit Specification Rules

• Test Units are specified by name or wildcard
• Scripts are specified by relative or absolute file name
• Tests (scripts or test units) are grouped together within curly braces, i.e. "{" and "}"
• When specifying more than one Test in a group, each Test instance must be delimited by a semicolon.
• When a Test accepts parameters they are passed following the Test name in parentheses comma separated, i.e. "myTest(param1, param2)"
• The output of each Test group is placed within a hierarchy of named suites. (The root suite does not have a name.)
• The suite into which a Test group is placed is specified immediately before the group, e.g. suitepath{testunitgroup}
• Hierarchical suite paths are delimited by "/" (forward slash) and are always specified starting from the root.
• If the same Test is specified to be run more than once, and one or more results are to be written to the same suite, the each conflicting Test name is appended with an incrementing count in the form of "(n)". For example: Results from three runs of TestUnit "myTest" are all written to the root suite. The Tests will be reported with the names "myTest" "myTest(1)" and "myTest(2)".

Wildcard Matching

The following wildcard characters are recognized in Test Unit specifications:

• * (asterisk) matches all Test Units
• - (hyphen) matches all remaining Test Units (useful when putting Test Units into suites)

Test Unit Specification Examples

-r "/{*}"

Run all Test Units and put results into the root-level suite.

-r "/Suite{*}"

Run all tests and put results into a suite named "Suite" that is a child of the root suite.

-r "/{Test1;Test2;Test3}"

Run the Tests named "Test1", "Test2", and "Test3" in the designated order; put results into the root suite.

-r "/{Test1;Test2;Test3}" -r "/SecondPass{Test1}"

Run the Tests named "Test1", "Test2", and "Test3" in the designated order; put results into the root suite. Then run the Test Unit named "Test1" again and put the results into a suite named "SecondPass".

-r "/{Test1;Test2;Test3}" -r "/Remaining{-}"

Run the Test Units named "Test1", "Test2", and "Test3" in the designated order; put results into the root suite. Then run all remaining Test Units and put the results into a suite named "Remaining".

-r "/Suite1/Suite2{TestA; TestB}"

Run the Tests named "TestA" and "TestB", and put the results into a suite named "Suite2" that is a child of a suite named "Suite1" that is a child of the root. Note that we must enclose the specification in quotes since the specification contains a space.

-r "/{TestA(29); TestB(5.67, \"some text\")}"

Run the Tests named "TestA" with parameter 29 and "TestB" with parameters 5.67 and "some text", and put the results into the root suite. Note that we must enclose the specification in quotes since the specification contains spaces and embedded quotes (which needs to be escaped using backslash).

-r "TestX; TestY; TestZ"

This is a special convenience syntax. If the suite and grouping braces are omitted, the app runs the the named Test Units and puts their results put into the root suite.

Output

Upon test completion, test output is always written as follows:

console output

A quick summary of results is written to standard output. Test counts are shown for the categories of passed, failed, in progress, and not in use

local xml file

Detailed results are written to a local xml file. By default, this file is written to the directory where the input STRIDE database file is located and given the same name as the database file with an extension of ".xml". If you open this file in a web browser, an xsl transform is automatically downloaded and applied before rendering.

Optionally, you may also publish the results to your STRIDE Test Space upon test completion.

Test Space

Results are uploaded using your Test Space URL and login credentials. You must specify the testspace name and project name when using this option.

Syntax

   stride [options] [TU...]

Each command line option that accepts an argument should be entered with a space between the option and its corresponding arguement; i.e.

stride -o argument --option1 argument1

Any warnings or errors that occur during execution are written to the standard output device.

Options

Option	Description
--version	Prints version information to the console.
--database arg	Specifies the name of an existing STRIDE database (.sidb) file that will be used for test execution. This can be a relative or absolute path. If the path contains one or more spaces, it must be enclosed in quotes. Under Windows, both DOS and UNC names are accepted. As a path delimiter you may use either the forward slash or backslash character. (Forward slashes are typically preferred due to the standard use of the backslash as an escape character.)
--device arg	Specifies the parameters to be used to connect to the target device (i.e. TCP:host:port or COMport:rate:mode). For example: TCP:localhost:8000 COM7:28800:8N1 /dev/ttyS2:57600:8N1
--timeout arg (=0)	Specifies a watchdog timeout (in seconds) per single test function or test method. Default value is 0. (0 = infinite timeout)
--run [ -r ] arg	Specifies a list of Test Units or Scripts to execute and their order of execution with optional report grouping by suite. You may specify this option many times on the command line to include multiple groupings in a single test. A named Test Suite may be specifed more than once to run it multiple times. See Input section above for more details. Any nameless positional option is treated as this option.
--trace [ -t ] arg (=txt)	Specifies if and how to trace on target instrumentation (functions, messages and test points/logs). The following types of tracing formats are supported: "txt" - single-entry-per-line plain text file "yml" - YAML formated file "-" - interactive single-entry-per-line plain text With the exception of the interactive type all others are attached as an annotation to the output file. Default value is "txt".
--trace_timeout arg	Specifies a trace timeout (in seconds).
--upload [ -u ] arg (=all)	Specifies if and how to upload the results to STRIDE Test Space. Arg specifies type of upload; The following types of uploads are supported: "all" - This causes a new result set to be created and marked complete. This is the most commonly needed upload type, so it is the default behavior. The remaining upload types are used to aggregate results of multiple executions into a single result set. "start" - This is used to create a new result set and mark it incomplete. An upload of this type should be followed by zero or more uploads that add results and one final upload that finishes the result set. "add" - This is used to add more data to an existing incomplete result set. The result set will still be marked incomplete after this upload type. "finish" - This is used to add more data to an existing incomplete result set and mark it complete. This is the last step in creating a result set from multiple executions. Default value is "all".
--testspace arg	Specifies the root STRIDE Test Space URL and credentials. (i.e. https://user:pwd@mycompany.stridetestspace.com)
--project arg	Specifies the name of the STRIDE Test Space project to which the results will be uploaded
--space arg	Specifies the name of the STRIDE Test Space project's test space.
--name arg	Specifies the name to be given to the result set uploaded to STRIDE Test Space. If this option is omitted, a default name of "Sequence_n" is used where n is an auto-incremented integer.
--list	Lists all Test Units and intercepted Functions in the specified STRIDE database to standard out.
--diagnostics	Performs a set of built-in diagnostic tests on the target. See Running Diagnostics for details.
--nocontinue	Causes the runner to exit immediately if a test method fails with one or more srEXITxx assertion. Default behavior is to continue executing the remaining test units.
--log_level arg (=warn)	Controls the target source test log (srTEST_LOGxx) level. The following levels are supported: "all" - enables all logging "info" - enables only INFO and higher "warn" - enables only WARN and higher "err" - enables only ERROR and higher "off" - disables all logging Default value is "warn".
--output [ -o ] arg	Specifies the local file to which test results will be written. Default output file is given the same name as the input database file (with the .sidb file extension replaced by .xml), and is written to the input database file's directory.
--options_file arg	Specifies a file from which the program reads command line options. The format is the same as the command line except that options may be split across multiple lines. Lines in an options file that begin with the character '#' are ignored.

Environment Variables

The following environment variables are recognized by the application and their values used as shown if set. Any value specifed by an environment variable will be overridden if the corresponding value is specified on the command line.

STRIDE_DEVICE

specifies the --device argument

STRIDE_TESTSPACE_URL

specifies the --testspace argument

STRIDE_TESTSPACE_PROJECT

specifies the --project argument

STRIDE_TESTSPACE_SPACE

specifies the --space argument

Setting up environment variable for static options will streamline the use of stride.

Using a Proxy

If you access the Internet via an HTTP proxy, you must set the environment variables HTTP_PROXY and HTTPS_PROXY to specify the name and port of the proxy server.

Symptoms of needing to specify a proxy is the following errors:

Unable to proceed. Invalid testspace address or credentials. Couldn't access the specified company. 
Failed performing request: [7] Couldn't connect to server

Unable to proceed. Failed performing request: [6] Couldn’t resolve host name

Define the environment variables in format host:port where host:port corresponding to your proxy server. For example, on Windows:

> set HTTP_PROXY=myproxy:8765
> set HTTPS_PROXY=myproxy:8765

would instruct the stride runner to use the proxy named myproxy on port 8765 to communicate via HTTP and HTTPS protocols.

If your proxy requires authentication use the format username:password@host:port where username and password are your credentials.

Examples

Refer to Running Tests for additional examples.

Publishing Pre-Existing Test Report Files

Stride.exe can be used to upload to Test Space one or more pre-existing report files only (without running tests).

To accomplish this specify the publishing-related parameters but do not specify the --device parameter or any --run parameters when you run stride. The file to be uploaded is specified by the --output parameter.

If you want aggregate more than one .xml file to a single Test Space result set, run stride once for each file to be uploaded, specifying the --upload parameter accordingly.

Note that stride will use any environment variables that are in effect, so if you have a non-empty value set for STRIDE_DEVICE it must be set to empty in your terminal session before upload-only will be performed. Similarly, environment variables STRIDE_TESTSPACE_URL, STRIDE_TESTSPACE_PROJECT, and STRIDE_TESTSPACE_SPACE will be used if non-empty. (These can be overridden on the command line.)

Examples

Upload a single report file

stride --testspace https://user:pwd@s2technologies.stridetestspace.com --project Sandbox --space "Tim Space" --name RSName --upload --output test.xml

Upload multiple report files to a single result set

Run stride once for each file to be aggregated. Note argument to --upload paramter.

stride --testspace https://user:pwd@s2technologies.stridetestspace.com --project Sandbox --space "Tim Space" --name RSName --upload start --output test1.xml

stride --testspace https://user:pwd@s2technologies.stridetestspace.com --project Sandbox --space "Tim Space" --name RSName --upload add --output test2.xml

stride --testspace https://user:pwd@s2technologies.stridetestspace.com --project Sandbox --space "Tim Space" --name RSName --upload add --output test3.xml

stride --testspace https://user:pwd@s2technologies.stridetestspace.com --project Sandbox --space "Tim Space" --name RSName --upload finish --output test4.xml