Listing Functions and Test Units - Revision history

Ivailop: /* Other Resources */

2010-05-17T20:45:03Z

Other Resources

← Older revision		Revision as of 20:45, 17 May 2010
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]].

Marku: /* Other Resources */

2010-04-29T03:14:16Z

Other Resources

← Older revision		Revision as of 03:14, 29 April 2010
Line 46:		Line 46:


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

Ivailop: /* List Output */

2010-02-18T18:52:40Z

List Output

← Older revision		Revision as of 18:52, 18 February 2010
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>

Mikee: moved Listing Test Units to Listing Functions and Test Units

2010-01-28T21:38:29Z

moved Listing Test Units to Listing Functions and Test Units

← Older revision	Revision as of 21:38, 28 January 2010
(No difference)

Mikee at 18:52, 28 January 2010

2010-01-28T18:52:10Z

← Older revision		Revision as of 18:52, 28 January 2010
Line 1:		Line 1:
	==Overview==		==Overview==
	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		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:		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 12:		Line 13:

	==List Output==		==List Output==
	~~Test~~ units 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).		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 ~~member test unit~~ in the .sidb file is listed, with one ~~test unit~~ per line. A sample of this output from the TestIntro build is shown below.		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.

	<pre>		<pre>
	s2_testintro_cclass		= Functions =
	s2_testintro_flist		run_through_all(int with_logs)
	s2_testintro_testdoubles		run_with_repitition()
	s2_testintro_testpoints		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>		</pre>

Timd at 16:08, 28 August 2009

2009-08-28T16:08:07Z

← Older revision		Revision as of 16:08, 28 August 2009
Line 32:		Line 32:
	Further, by redirecting the output to a file, you can create a stride command file with a little editing.		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 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 A Subset of Tests#Automating the Running of a Stubset of Tests\|here]].

Timd at 16:07, 28 August 2009

2009-08-28T16:07:19Z

← Older revision		Revision as of 16:07, 28 August 2009
Line 34:		Line 34:
	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 A Subset of Tests#Automating the Running of a Stubset of Tests\|here]].

	~~The perl script shown above reads from stdin and attempts to match the line to the regular expression <tt>myPrefix_</tt>. If a match is detected, the~~ line ~~is written to stdout prefixed with <tt>-r </tt>,~~		For full details on stride command line parameters, please see [[STRIDE Runner]].

	~~If you save this script to a file named myTests.pl~~, ~~you can automate the running of tests that match your prefix as follows:~~

	~~stride --list --database TestApp.sidb \| perl myTests.pl > tests.txt~~
	~~stride --database TestApp.sidb -O tests~~.~~txt~~


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

Timd at 16:05, 28 August 2009

2009-08-28T16:05:35Z

← Older revision		Revision as of 16:05, 28 August 2009
Line 32:		Line 32:
	Further, by redirecting the output to a file, you can create a stride command file with a little editing.		Further, by redirecting the output to a file, you can create a stride command file with a little editing.

	~~===Using Perl===~~		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]].
	~~You can~~ automate the ~~creation~~ of a ~~stride command file using perl~~.

	~~<source lang="perl">~~
	~~while( <> ) {~~
	~~if( /myPrefix_*/) {~~
	~~print "-r $_";~~
	}
	}
	~~</source>~~

	The perl script shown above reads from stdin and attempts to match the line to the regular expression <tt>myPrefix_</tt>. If a match is detected, the line is written to stdout prefixed with <tt>-r </tt>,		The perl script shown above reads from stdin and attempts to match the line to the regular expression <tt>myPrefix_</tt>. If a match is detected, the line is written to stdout prefixed with <tt>-r </tt>,

Timd at 15:57, 28 August 2009

2009-08-28T15:57:05Z

@@ 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==
 * Verifying that a particular test unit is available in a specific build
@@ Line 9: / Line 11: @@
   stride --list --database TestApp.sidb
 [[Category:Running Tests & Publishing Results]]

Timd at 00:22, 27 August 2009

2009-08-27T00:22:12Z

← Older revision		Revision as of 00:22, 27 August 2009
Line 3:		Line 3:
	* Verifying that a particular test unit is available in a specific build		* Verifying that a particular test unit is available in a specific build
	* 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

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