Running Tests (old) - Revision history

Marku: Marku moved page Running Tests to Running Tests (old)

2015-07-06T19:33:08Z

Marku moved page Running Tests to Running Tests (old)

← Older revision	Revision as of 19:33, 6 July 2015
(No difference)

Timd: /* Examples */

2013-02-26T21:08:12Z

Examples

← Older revision		Revision as of 21:08, 26 February 2013
Line 130:		Line 130:

	;Upload multiple report files to a single result set		;Upload multiple report files to a single result set
	:Run stride once for each file to be aggregated. Note argument to <tt>--upload</tt> ~~paramter~~.		:Run stride once for each file to be aggregated. Note argument to <tt>--upload</tt> parameter.

	<pre>		<pre>
Line 141:		Line 141:
	stride --testspace <nowiki>user:pwd@s2technologies.stridetestspace.com</nowiki> --project Sandbox --space "Tim Space" --name RSName --upload finish --output test4.xml		stride --testspace <nowiki>user:pwd@s2technologies.stridetestspace.com</nowiki> --project Sandbox --space "Tim Space" --name RSName --upload finish --output test4.xml
	</pre>		</pre>

	==Other Resources==		==Other Resources==
	A technique to organize tests into suites is shown [[Organizing Tests into Suites\|here]].		A technique to organize tests into suites is shown [[Organizing Tests into Suites\|here]].

Timd at 21:07, 26 February 2013

2013-02-26T21:07:41Z

@@ Line 114: / Line 114: @@
 '''Note:''' In order for publishing to succeed, the username/password must be correct and the project and space must already exist. If you are using TestSpace for the first time, you should check with your administrator about how to create projects and spaces.
 ==Other Resources==
 A technique to organize tests into suites is shown [[Organizing Tests into Suites|here]].

Ivailop: /* Example: Desktop Testing with Publication to Test Space */

2013-02-20T20:47:22Z

Example: Desktop Testing with Publication to Test Space

← Older revision		Revision as of 20:47, 20 February 2013
Line 103:		Line 103:
	--run "/{myTest1;myTest2; myTest3}"		--run "/{myTest1;myTest2; myTest3}"
	--upload		--upload
	--testspace ~~https://~~username:password@mycompany.stridetestspace.com		--testspace username:password@mycompany.stridetestspace.com
	--project "Super Repeater"		--project "Super Repeater"
	--space "Input Processor"		--space "Input Processor"

Ivailop: /* Running All Tests */

2011-11-24T23:04:34Z

Running All Tests

← Older revision		Revision as of 23:04, 24 November 2011
Line 40:		Line 40:
	There is no way to run ''all'' perl test modules since we don't capture information about these in the STRIDE database. However, if you organize your test modules in a directory hierarchy, the [[Stride_Runner\|runner]] provides a convenient syntax for executing all test modules in a directory - for example:		There is no way to run ''all'' perl test modules since we don't capture information about these in the STRIDE database. However, if you organize your test modules in a directory hierarchy, the [[Stride_Runner\|runner]] provides a convenient syntax for executing all test modules in a directory - for example:

	stride --database TestApp.sidb --device TCP:128.0.0.1:8000 --run=path\to\my_directory		stride --database TestApp.sidb --device TCP:128.0.0.1:8000 --run "path/to/my_directory"

	will recursively search ''my_directory'' for script test modules (identified by file extension) and execute each as it is found.		will recursively search ''my_directory'' for script test modules (identified by file extension) and execute each as it is found.

Ivailop: /* Running Tests */

2011-11-24T23:04:06Z

Running Tests

← Older revision		Revision as of 23:04, 24 November 2011
Line 23:		Line 23:
	The command line to run the desired tests would be:		The command line to run the desired tests would be:
	<pre>		<pre>
	stride -r "myTest1;myTest2;myTest3" -r myScriptTests.pm --database="/my/path/targetApp.sidb" --device=TCP:192.168.0.53:8000		stride --run "myTest1;myTest2;myTest3" --run myScriptTests.pm --database "/my/path/targetApp.sidb" --device TCP:192.168.0.53:8000
	</pre>		</pre>

Line 34:		Line 34:
	By default, stride will not run any tests if <tt>--run</tt> options are not specified. A simple way to run ''all'' target based test units (tests implemented in native code on the device) is to specify the wildcard parameter to stride - specifically:		By default, stride will not run any tests if <tt>--run</tt> options are not specified. A simple way to run ''all'' target based test units (tests implemented in native code on the device) is to specify the wildcard parameter to stride - specifically:

	stride --database TestApp.sidb --device TCP:128.0.0.1:8000 --run="*"		stride --database TestApp.sidb --device TCP:128.0.0.1:8000 --run "*"

	This will cause all test units that have been captured in the STRIDE database to be executed.		This will cause all test units that have been captured in the STRIDE database to be executed.

Ivailop: /* Running A Subset of Tests */

2011-11-24T23:03:17Z

Running A Subset of Tests

← Older revision		Revision as of 23:03, 24 November 2011
Line 51:		Line 51:
	The following command line will run the three tests in the order shown, putting their results into the root test suite.		The following command line will run the three tests in the order shown, putting their results into the root test suite.

	stride --database TestApp.sidb -r /{MyTest1;MyTest2;MyTest3}		stride --database TestApp.sidb --run /{MyTest1;MyTest2;MyTest3}

	Or, if your test results are to be published in the root suite, you can use this simplified syntax:		Or, if your test results are to be published in the root suite, you can use this simplified syntax:

Ivailop: /* Example: Desktop Testing with Publication to Test Space */

2011-11-24T23:02:55Z

Example: Desktop Testing with Publication to Test Space

← Older revision		Revision as of 23:02, 24 November 2011
Line 101:		Line 101:
	--database "/my/path/targetApp.sidb"		--database "/my/path/targetApp.sidb"
	--device TCP:192.168.0.53:8000		--device TCP:192.168.0.53:8000
	-r "/{myTest1;myTest2; myTest3}"		--run "/{myTest1;myTest2; myTest3}"
	-u		--upload
	--testspace https://username:password@mycompany.stridetestspace.com		--testspace https://username:password@mycompany.stridetestspace.com
	--project "Super Repeater"		--project "Super Repeater"
	--space "Input Processor"		--space "Input Processor"
	-o myoutputfile.xml		--output myoutputfile.xml
	</pre>		</pre>

	The command line is then:		The command line is then:
	stride -O "myOptions.txt"		stride --options_file "myOptions.txt"

	'''Note:''' In order for publishing to succeed, the username/password must be correct and the project and space must already exist. If you are using TestSpace for the first time, you should check with your administrator about how to create projects and spaces.		'''Note:''' In order for publishing to succeed, the username/password must be correct and the project and space must already exist. If you are using TestSpace for the first time, you should check with your administrator about how to create projects and spaces.

Ivailop: /* Running A Subset of Tests */

2011-11-24T23:02:01Z

Running A Subset of Tests

← Older revision		Revision as of 23:02, 24 November 2011
Line 72:		Line 72:

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

	== Publishing Test Results ==		== Publishing Test Results ==

Ivailop: /* Running All Tests */

2011-11-24T22:54:33Z

Running All Tests

← Older revision		Revision as of 22:54, 24 November 2011
Line 38:		Line 38:
	This will cause all test units that have been captured in the STRIDE database to be executed.		This will cause all test units that have been captured in the STRIDE database to be executed.

	There is no way to run ''all'' test modules since we don't capture information about these in the STRIDE database. However, if you organize your test modules in a directory hierarchy, the [[Stride_Runner\|runner]] provides a convenient syntax for executing all test modules in a directory - for example:		There is no way to run ''all'' perl test modules since we don't capture information about these in the STRIDE database. However, if you organize your test modules in a directory hierarchy, the [[Stride_Runner\|runner]] provides a convenient syntax for executing all test modules in a directory - for example:

	stride --database TestApp.sidb --device TCP:128.0.0.1:8000 --run=path\to\my_directory		stride --database TestApp.sidb --device TCP:128.0.0.1:8000 --run=path\to\my_directory