Parameterized Test Units - Revision history

Marku at 15:36, 6 July 2015

2015-07-06T15:36:26Z

← Older revision		Revision as of 15:36, 6 July 2015
Line 1:		Line 1:
	__NOTOC__		__NOTOC__
	Stride provides an easy way for passing parameters from the [[STRIDE Runner]] on the host to the test code executing on the target device.		Stride provides an easy way for passing parameters from the [[STRIDE Runner \| Stride Runner]] on the host to the test code executing on the target device.

	Pass parameters via the command line to your constructor		Pass parameters via the command line to your constructor
Line 56:		Line 56:
	'''NOTE:''' ''Don't declare more ''than one'' public constructor. This is typically not a problem for non-parameterized test classes, as a common [http://en.wikipedia.org/wiki/Nullary_constructor default constructor] is what's needed. Often you will begin with a non-parameterized test class and add the parameterization later as your testing gets more sophisticated. A common mistake here is to add a second public parameterized constructor to the class in addition to the original default constructor; this is perfectly legal in C++, but will not give you the desired result.''		'''NOTE:''' ''Don't declare more ''than one'' public constructor. This is typically not a problem for non-parameterized test classes, as a common [http://en.wikipedia.org/wiki/Nullary_constructor default constructor] is what's needed. Often you will begin with a non-parameterized test class and add the parameterization later as your testing gets more sophisticated. A common mistake here is to add a second public parameterized constructor to the class in addition to the original default constructor; this is perfectly legal in C++, but will not give you the desired result.''

	'''NOTE:''' ''Don't set default values for your constructor arguments. In the case of ~~STRIDE~~, each test class is instantiated dynamically on demand by the harnessing code. The harnessing code does not know at build time whether constructor parameters will be omitted when the class is ultimately instantiated. (See bellow how constructor arguments are specified on the ~~STRIDE~~ Runner command line on the host computer.)''		'''NOTE:''' ''Don't set default values for your constructor arguments. In the case of Stride, each test class is instantiated dynamically on demand by the harnessing code. The harnessing code does not know at build time whether constructor parameters will be omitted when the class is ultimately instantiated. (See bellow how constructor arguments are specified on the Stride Runner command line on the host computer.)''

	;C-Class Test Unit		;C-Class Test Unit
Line 81:		Line 81:
	#endif		#endif
	</source>		</source>


	<source lang=c>		<source lang=c>
Line 108:		Line 109:

	=== How to pass via the Runner ===		=== How to pass via the Runner ===
	To pass parameter values as constructor arguments you need to specify them between parentheses characters immediately following the Test Unit name on the [[STRIDE Runner]] command line:		To pass parameter values as constructor arguments you need to specify them between parentheses characters immediately following the Test Unit name on the [[STRIDE Runner \| Stride Runner]] command line:

	;Number argument		;Number argument
Line 193:		Line 194:
	#endif		#endif
	</source>		</source>


	<source lang=c>		<source lang=c>
Line 220:		Line 222:

	=== How to pass via the Runner ===		=== How to pass via the Runner ===
	To pass parameter values as name-value collection you need to create an [http://en.wikipedia.org/wiki/INI_file INI-formatted file] and specify it ('''without double quite''' encloser) between parentheses characters immediately following the Test Unit name on the [[STRIDE Runner]] command line:		To pass parameter values as name-value collection you need to create an [http://en.wikipedia.org/wiki/INI_file INI-formatted file] and specify it ('''without double quite''' encloser) between parentheses characters immediately following the Test Unit name on the [[STRIDE Runner \| Stride Runner]] command line:
	--run="MyTest(/path/to/file.ini)"		--run="MyTest(/path/to/file.ini)"

Marku at 13:31, 3 July 2015

2015-07-03T13:31:05Z

← Older revision		Revision as of 13:31, 3 July 2015
Line 11:		Line 11:


	This allows customization of the test behavior at ~~run time~~ and is useful when you want to run the same test scenario with different sets of input data, as described by [http://xunitpatterns.com/Parameterized%20Test.html this pattern].		This allows customization of the test behavior at runtime and is useful when you want to run the same test scenario with different sets of input data, as described by [http://xunitpatterns.com/Parameterized%20Test.html this pattern].

	There are two ways you could pass parameters:		There are two ways you could pass parameters:

Marku at 16:00, 1 July 2015

2015-07-01T16:00:33Z

← Older revision		Revision as of 16:00, 1 July 2015
Line 241:		Line 241:

	'''NOTE:''' ''String values are not required to be double quote enclosed.''		'''NOTE:''' ''String values are not required to be double quote enclosed.''

	~~[[Category: Test Units]]~~

Marku at 16:00, 1 July 2015

2015-07-01T16:00:10Z

← Older revision		Revision as of 16:00, 1 July 2015
Line 1:		Line 1:
	== ~~Introduction ==~~		__NOTOC__
			Stride provides an easy way for passing parameters from the [[STRIDE Runner]] on the host to the test code executing on the target device.

			Pass parameters via the command line to your constructor

			stride .. --run=MyTest(42)

			Pass parameters using a name-value collection

			stride .. --run="MyOtherTest(/path/to/file.ini)"


	~~The STRIDE Framework provides an easy way for passing parameters from the [[STRIDE Runner]] on the host to the test code executing on the target device.~~
	This allows customization of the test behavior at run time and is useful when you want to run the same test scenario with different sets of input data, as described by [http://xunitpatterns.com/Parameterized%20Test.html this pattern].		This allows customization of the test behavior at run time and is useful when you want to run the same test scenario with different sets of input data, as described by [http://xunitpatterns.com/Parameterized%20Test.html this pattern].

Ivailop at 00:04, 1 December 2014

2014-12-01T00:04:35Z

Show changes

Ivailop: /* Additional Tips When Using Parameters */

2014-11-27T01:02:06Z

Additional Tips When Using Parameters

← Older revision		Revision as of 01:02, 27 November 2014
Line 299:		Line 299:
	</source>		</source>

	~~==Additional Tips When Using Parameters==~~

	~~===Setting the Test Unit Name Dynamically===~~
	The purpose of parameterizing a test unit is to provide additional test coverage using a single test unit implementation. In a single stride.exe invocation you will typically run the same test unit many times, passing a different set of parameters for each test.

	~~<small>~~
	~~'''Note:''' Option files are a necessity, since the stride.exe command line gets unwieldy in these situations. Option files give you repeatibility and also eliminate a lot of typing!~~
	~~</small>~~

	~~===Test Units With Many Parameters===~~
	~~----~~
	~~;Notes~~
	~~<references/>~~
	[[Category: Test Units]]		[[Category: Test Units]]

Ivailop: /* Don't Declare More Than One Public Constructor */

2014-11-27T01:00:04Z

Don't Declare More Than One Public Constructor

← Older revision		Revision as of 01:00, 27 November 2014
Line 193:		Line 193:
	You must declare '''only one''' public constructor in a test class.		You must declare '''only one''' public constructor in a test class.

	This is typically not a problem for non-parameterized test classes, as a common ~~default constructor <ref>more specifically a~~ [http://en.wikipedia.org/wiki/Nullary_constructor ~~nullary~~ constructor] ~~</ref>~~ is what's needed. Often you will begin with a non-parameterized test class and add the parameterization later as your testing gets more sophisticated. A common mistake here is to add a second public parameterized constructor to the class in addition to the original default constructor; this is perfectly legal in C++, but will not give you the desired result.		This is typically not a problem for non-parameterized test classes, as a common [http://en.wikipedia.org/wiki/Nullary_constructor default constructor] is what's needed. Often you will begin with a non-parameterized test class and add the parameterization later as your testing gets more sophisticated. A common mistake here is to add a second public parameterized constructor to the class in addition to the original default constructor; this is perfectly legal in C++, but will not give you the desired result.

	You must ensure that you have only one public class constructor.		You must ensure that you have only one public class constructor.

Timd at 21:36, 17 April 2012

2012-04-17T21:36:54Z

← Older revision		Revision as of 21:36, 17 April 2012
Line 3:		Line 3:
	==How Parameters are Passed from the Host==		==How Parameters are Passed from the Host==
	Parameters to be passed to a target test unit are supplied on the stride.exe command line used to invoke the test unit. Test unit parameter values are specified between parentheses characters immediately following the test unit name on the command line.		Parameters to be passed to a target test unit are supplied on the stride.exe command line used to invoke the test unit. Test unit parameter values are specified between parentheses characters immediately following the test unit name on the command line.

			===Parameter Rules===

			* String parameters are enclosed with double quotes
			* Number parameters are not quoted

			Additionally, the command processor imposes these rules:
			* If the run option's value contains one or more spaces (except within a quoted string parameter), it must be enclosed within double-quotes.
			** Within these quotes, all double-quote and backslash characters must be escaped with a preceding backslash

	===Number Parameter===		===Number Parameter===
Line 18:		Line 27:
	</pre>		</pre>

	Note that the string parameter must be enclosed with double quote characters. The double quotes are escaped with a backslash as this is required by the command line processor.		Note that the string parameter must be enclosed with double quote characters. The double quotes are escaped with a backslash as this is required by the command line processor. Here you are not required to enclose the

	====Parameter Containing Spaces====		====Parameter Containing Spaces====
Line 28:		Line 37:
	</pre>		</pre>

	Note that the command line processor requires you to enclose with double quotes if there are any spaces at all in the <tt>--run</tt> argument. This can be counter-intuitive when passing only number types.

	;~~No space in argument list~~		===File Path Parameters===
	~~<pre>~~		File paths are a special case of string parameters; they require special handling due to their path delimiters.
	--~~run=TestX~~(~~123,555,3~~.~~14)~~
	~~</pre>~~		On Windows systems, file paths are delimited using the backslash character ('\') which must be escaped within a string parameter. A simpler approach (recommended) is to use forward-slashes to delimit any file path that is passed as a parameter. These file paths with forward-slash delimiters can be used directly by the stride file stuff on the target (even when the host system is running under Windows).

	~~;Space in argument list~~		For example:
	<pre>		<pre>
	--run="~~TestX~~(~~123, 555, 3~~.14)"		--run="FileTest(\"c:/myData Test/testParams.ini\")"
	</pre>		</pre>

	~~===File Path Parameters===~~		''Note that in this example the file path has a space in it, so that the entire run parameter must be enclosed in double quotes.''
	~~File paths are~~ a ~~special case of string parameters; they require special handling due to their path delimiters.~~

	~~On Windows systems~~, ~~file paths are delimited using~~ the ~~backslash character (~~'\')

	===Multiple Parameters===		===Multiple Parameters===
Line 54:		Line 59:
	A few additional examples are shown on the STRIDE Test Runner [[STRIDE_Runner#Test_Unit_Specification_Examples \| Reference page]].		A few additional examples are shown on the STRIDE Test Runner [[STRIDE_Runner#Test_Unit_Specification_Examples \| Reference page]].

			Note that the command line processor requires you to enclose with double quotes if there are any spaces at all in the <tt>--run</tt> argument. This can be counter-intuitive when passing only number types.

			;No space in argument list
			<pre>
			--run=TestX(123,555,3.14)
			</pre>

			;Space in argument list
			<pre>
			--run="TestX(123, 555, 3.14)"
			</pre>

	==How Parameters are Received on the Target==		==How Parameters are Received on the Target==

Timd: /* String Parameter */

2012-04-17T20:27:45Z

String Parameter

← Older revision		Revision as of 20:27, 17 April 2012
Line 39:		Line 39:
	--run="TestX(123, 555, 3.14)"		--run="TestX(123, 555, 3.14)"
	</pre>		</pre>

			===File Path Parameters===
			File paths are a special case of string parameters; they require special handling due to their path delimiters.

			On Windows systems, file paths are delimited using the backslash character ('\')

	===Multiple Parameters===		===Multiple Parameters===

Timd at 17:09, 14 February 2012

2012-02-14T17:09:57Z

← Older revision		Revision as of 17:09, 14 February 2012
Line 152:		Line 152:
	==Supported Parameter Types==		==Supported Parameter Types==

	ANSI~~/Unicode~~ strings and number parameter types are directly supported.		ANSI strings and number parameter types are directly supported.

	{\| class="wikitable"		{\| class="wikitable"
	\|-		\|-
	\| '''String types''' \|\|		\| '''String types''' \|\|
	~~;ANSI~~
	* <tt>char*</tt>		* <tt>char*</tt>
	* <tt>const char*</tt>		* <tt>const char*</tt>
	~~;Unicode~~
	* <tt>short*</tt>
	* <tt>const short*</tt>
	~~''Where '''wchar_t''' is a built-in type, pointers to this type are also supported''~~
	\|-		\|-
	\| '''Number types''' \|\|		\| '''Number types''' \|\|
Line 211:		Line 206:
	** The test class declaration does not need to specify default arguments for the above to work. (In fact the default arguments won't be used!)		** The test class declaration does not need to specify default arguments for the above to work. (In fact the default arguments won't be used!)

	* Any arguments that are omitted will be supplied to the constructor with the value 0 ~~for number types and empty~~ (~~zero-length) string~~ for ~~character~~ pointer types.		* Any arguments that are omitted will be supplied to the constructor with the value 0 (or NULL for char pointer types).

	====Example====		====Example====
Line 224:		Line 219:
	// Default parameter values WILL NOT be used!		// Default parameter values WILL NOT be used!
	// If a parameter is not specified on stride command line,		// If a parameter is not specified on stride command line,
	// its value is always passed to the constructor as 0 ~~or empty string~~		// its value is always passed to the constructor as 0
	MyTest(int param1 = 100, int param2 = 200); // WRONG! DON'T DO THIS!		MyTest(int param1 = 100, int param2 = 200); // WRONG! DON'T DO THIS!
	...		...
Line 282:		Line 277:

	</source>		</source>

			==Additional Tips When Using Parameters==

			===Setting the Test Unit Name Dynamically===
			The purpose of parameterizing a test unit is to provide additional test coverage using a single test unit implementation. In a single stride.exe invocation you will typically run the same test unit many times, passing a different set of parameters for each test.

			<small>
			'''Note:''' Option files are a necessity, since the stride.exe command line gets unwieldy in these situations. Option files give you repeatibility and also eliminate a lot of typing!
			</small>

			===Test Units With Many Parameters===
	----		----
	;Notes		;Notes
	<references/>		<references/>
	[[Category: Test Units]]		[[Category: Test Units]]