Listing Functions and Test Units: Difference between revisions

From STRIDE Wiki
Jump to navigation Jump to search
 
(2 intermediate revisions by 2 users not shown)
Line 18: Line 18:


<pre>
<pre>
= Functions =
Functions
run_through_all(int with_logs)
  run_through_all(int with_logs)
run_with_repitition()
  run_with_repitition()
s2MoveString(char const * p1, char * p2)
  s2MoveString(char const * p1, char * p2)
= Test Units =
Test Units
s2_testintro_cclass()
  s2_testintro_cclass()
s2_testintro_flist()
  s2_testintro_flist()
s2_testintro_parameters(char const * szString, unsigned int uExpectedLen, unsigned int uExpectedNumberOfSpaces)
  s2_testintro_parameters(char const * szString, unsigned int uExpectedLen, unsigned int uExpectedNumberOfSpaces)
s2_testintro_testdoubles()
  s2_testintro_testdoubles()
s2_testintro_testpoints()
  s2_testintro_testpoints()
s2_testpoint_basic()
  s2_testpoint_basic()
</pre>
</pre>


Line 41: Line 41:


==Other Resources==
==Other Resources==
A technique using stride's list capability to automate the running of a subset of tests is shown [[Running A Subset of Tests#Automating the Running of a Stubset of Tests|here]].
A technique using stride's list capability to automate the running of a subset of tests is shown [[Running_Tests#Running A Subset of Tests|here]].


For full details on stride command line parameters, please see [[STRIDE Runner]].
For full details on stride command line parameters, please see [[STRIDE Runner]].




[[Category:Running Tests & Publishing Results]]
[[Category:Running Tests]]

Latest revision as of 20:45, 17 May 2010

Overview

While the STRIDE runner is mainly used to execute tests, it can also be used to list the test units and remote functions that are available in a target build. The listing capability is useful in several scenarios:

  • Verifying that a particular function or test unit is available in a specific build
  • Verifying the parameters to a function or test unit (test unit params are optional, even if declared)
  • Creating a command file that will be used to run only tests who's names match a specific text pattern
  • Creating a command file that will be used to run all tests in a particular order

To list the available test units, run stride giving it command line parameters as follows:

stride --list --database TestApp.sidb

List Output

The two supported items (functions and test units) are grouped together. Within each group, the items are listed in the order they are encountered in the .sidb file (which reflects the order they were seen by the stride compiler when the target was built).

Each item in the .sidb file is listed, with one item per line and showing the parameters, if any. A sample of this output from the TestIntro build is shown below.

Functions
  run_through_all(int with_logs)
  run_with_repitition()
  s2MoveString(char const * p1, char * p2)
Test Units
  s2_testintro_cclass()
  s2_testintro_flist()
  s2_testintro_parameters(char const * szString, unsigned int uExpectedLen, unsigned int uExpectedNumberOfSpaces)
  s2_testintro_testdoubles()
  s2_testintro_testpoints()
  s2_testpoint_basic()

Advanced List Usage

The list output can be piped to another program such as grep in order to create a list of test units filtered by name characteristics.

For instance, suppose that you want to run only the test units owned by your department or development group from a target build that includes many tests aggregated from others. Provided that your test units follow a unique naming convention, you can create a filtered list as follows:

stride --list --database TestApp.sidb | grep myPrefix_*

Further, by redirecting the output to a file, you can create a stride command file with a little editing.

Other Resources

A technique using stride's list capability to automate the running of a subset of tests is shown here.

For full details on stride command line parameters, please see STRIDE Runner.