Listing Functions and Test Units: Difference between revisions
No edit summary |
|||
(8 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
While the STRIDE runner is mainly used to execute tests, it can also be used to list the test units that are available in a target build. | ==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 test unit is available in a specific build | * 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 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 | * Creating a command file that will be used to run all tests in a particular order | ||
Line 9: | Line 12: | ||
stride --list --database TestApp.sidb | 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. | |||
[[Category:Running Tests | <pre> | ||
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() | |||
</pre> | |||
==Advanced List Usage== | |||
The list output can be piped to another program such as <tt>[http://en.wikipedia.org/wiki/Grep grep]</tt> 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 [[Running_Tests#Running A Subset of Tests|here]]. | |||
For full details on stride command line parameters, please see [[STRIDE Runner]]. | |||
[[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.