Test Macros - Revision history

Ivailop: /* Guidelines */

2015-09-29T22:25:51Z

Guidelines

Ryanh at 19:57, 7 July 2015

2015-07-07T19:57:24Z

← Older revision		Revision as of 19:57, 7 July 2015
Line 45:		Line 45:
	Note that the supplemental information is put into the test report only if the macro fails. For example <tt>srEXPECT_EQ(a, 10)</tt>, if a equals 10, then no action is taken; if a is not equal to 10, then the normal srEXPECT actions are taken, and--in addition--the supplemental information is added to the failure record in the test report. The ''srEXIT_xx()'' macro does not support this feature.		Note that the supplemental information is put into the test report only if the macro fails. For example <tt>srEXPECT_EQ(a, 10)</tt>, if a equals 10, then no action is taken; if a is not equal to 10, then the normal srEXPECT actions are taken, and--in addition--the supplemental information is added to the failure record in the test report. The ''srEXIT_xx()'' macro does not support this feature.

	The following sections document the several types of testing macros that are provided by the ~~STRIDE~~ Framework. For simplicity, we refer to all the macros using a '''''prefix''''' tag - when using the macros in test code, the '''''prefix''''' should be replaced by one of the following: '''srEXPECT''', '''srASSERT''', or '''srEXIT''', depending on how the test writer wants failures to be handled.		The following sections document the several types of testing macros that are provided by the Stride Framework. For simplicity, we refer to all the macros using a '''''prefix''''' tag - when using the macros in test code, the '''''prefix''''' should be replaced by one of the following: '''srEXPECT''', '''srASSERT''', or '''srEXIT''', depending on how the test writer wants failures to be handled.

	== Boolean Macros ==		== Boolean Macros ==
Line 302:		Line 302:

	== Dynamic Test Case Macros ==		== Dynamic Test Case Macros ==
	The macros presented so far assume that their actions are directed at the ~~currenly~~ in-scope test case. However, test cases can be created dynamically using ~~STRIDE~~'s [Runtime Test Services].		The macros presented so far assume that their actions are directed at the currently in-scope test case. However, test cases can be created dynamically using Stride's [Runtime Test Services].

	In order to handle dynamic test cases, each of the macros requires another parameter which specifies the test case to report against. Other than this, these macros provide exactly equivalent functionality to the non-dynamic peer. The dynamic macros are listed below. All require a test case, value of type '''srTestCaseHandle_t''' from srtest.h, to be passed as the first parameter).		In order to handle dynamic test cases, each of the macros requires another parameter which specifies the test case to report against. Other than this, these macros provide exactly equivalent functionality to the non-dynamic peer. The dynamic macros are listed below. All require a test case, value of type '''srTestCaseHandle_t''' from srtest.h, to be passed as the first parameter).

Ryanh at 16:35, 7 July 2015

2015-07-07T16:35:08Z

← Older revision		Revision as of 16:35, 7 July 2015
Line 43:		Line 43:


	Note that the supplemental information is put into the test report only if the macro fails. ~~In the case above~~, if a equals 10, then no action is taken; if a is not equal to 10, then the normal srEXPECT actions are taken, and--in addition--the supplemental information is added to the failure record in the test report. The ''srEXIT_xx()'' macro does not support this feature.		Note that the supplemental information is put into the test report only if the macro fails. For example <tt>srEXPECT_EQ(a, 10)</tt>, if a equals 10, then no action is taken; if a is not equal to 10, then the normal srEXPECT actions are taken, and--in addition--the supplemental information is added to the failure record in the test report. The ''srEXIT_xx()'' macro does not support this feature.

	The following sections document the several types of testing macros that are provided by the STRIDE Framework. For simplicity, we refer to all the macros using a '''''prefix''''' tag - when using the macros in test code, the '''''prefix''''' should be replaced by one of the following: '''srEXPECT''', '''srASSERT''', or '''srEXIT''', depending on how the test writer wants failures to be handled.		The following sections document the several types of testing macros that are provided by the STRIDE Framework. For simplicity, we refer to all the macros using a '''''prefix''''' tag - when using the macros in test code, the '''''prefix''''' should be replaced by one of the following: '''srEXPECT''', '''srASSERT''', or '''srEXIT''', depending on how the test writer wants failures to be handled.
Line 192:		Line 192:
	Predicate macros allow user control over the pass/fail decision making.		Predicate macros allow user control over the pass/fail decision making.

	A predicate is a function returning bool that is implemented by the user ~~that is the macro~~. Up to four arguments can also passed to the predicate through the macro.		A predicate is a function returning bool that is implemented by the user. Up to four arguments can also passed to the predicate through the macro.

	{\| class="prettytable"		{\| class="prettytable"

Marku: /* Guidelines */

2015-07-06T19:53:27Z

Guidelines

← Older revision		Revision as of 19:53, 6 July 2015
Line 43:		Line 43:


	Note that the supplemental information is put into the test report only if the macro fails. In the case above, if a equals 10, then no action is taken; if a is not equal to 10, then the normal srEXPECT actions are taken, and--in addition--the supplemental information is added to the failure record in the test report. The ''srEXIT_xx()'' macro does not support this feature~~. For more information please read [[C%2B%2B_Only_Features\|this]]~~.		Note that the supplemental information is put into the test report only if the macro fails. In the case above, if a equals 10, then no action is taken; if a is not equal to 10, then the normal srEXPECT actions are taken, and--in addition--the supplemental information is added to the failure record in the test report. The ''srEXIT_xx()'' macro does not support this feature.

	The following sections document the several types of testing macros that are provided by the STRIDE Framework. For simplicity, we refer to all the macros using a '''''prefix''''' tag - when using the macros in test code, the '''''prefix''''' should be replaced by one of the following: '''srEXPECT''', '''srASSERT''', or '''srEXIT''', depending on how the test writer wants failures to be handled.		The following sections document the several types of testing macros that are provided by the STRIDE Framework. For simplicity, we refer to all the macros using a '''''prefix''''' tag - when using the macros in test code, the '''''prefix''''' should be replaced by one of the following: '''srEXPECT''', '''srASSERT''', or '''srEXIT''', depending on how the test writer wants failures to be handled.

Marku at 16:56, 6 July 2015

2015-07-06T16:56:27Z

← Older revision		Revision as of 16:56, 6 July 2015
Line 1:		Line 1:
	__NOTOC__		__NOTOC__
	The Stride implementation of [http://en.wikipedia.org/wiki/Assertion_(software_development) assertions] are provided with a set of Test Macros (declared in srtest.h) available for use within test methods. The macros are optional - you are not required to use them in your '''Test Units''. They provide shortcuts for testing assertions and automatic report annotation in the case of failures.		The Stride implementation of [http://en.wikipedia.org/wiki/Assertion_(software_development) assertions] are provided with a set of Test Macros (declared in srtest.h) available for use within test methods. The macros are optional - you are not required to use them in your '''Test Units'''. They provide shortcuts for testing assertions and automatic report annotation in the case of failures.

	'''Example Test Macros'''		'''Example Test Macros'''

Marku: /* Guidelines */

2015-07-03T12:55:58Z

Guidelines

← Older revision		Revision as of 12:55, 3 July 2015
Line 19:		Line 19:
	== Guidelines ==		== Guidelines ==

	There are ~~four~~ types of macros: '''EXPECT''', '''ASSERT''', '''EXIT~~''', and '''NOTE~~''' macros. They have slight but important differences in their behavior.		There are three types of macros: '''EXPECT''', '''ASSERT''', and '''EXIT''' macros. They have slight but important differences in their behavior.

	'''srEXPECT_''xx''('''''condition''''')'''		'''srEXPECT_''xx''('''''condition''''')'''

Marku at 15:21, 1 July 2015

2015-07-01T15:21:01Z

@@ Line 43: / Line 43: @@
-''' ''Hint:'' A simple way to add supplemental information to test failures'''
+Note that the supplemental information is put into the test report only if the macro fails. In the case above, if a equals 10, then no action is taken; if a is not equal to 10, then the normal srEXPECT actions are taken, and--in addition--the supplemental information is added to the failure record in the test report. The ''srEXIT_xx()'' macro does not support this feature. For more information please read [[C%2B%2B_Only_Features|this]].
 The following sections document the several types of testing macros that are provided by the STRIDE Framework. For simplicity, we refer to all the macros using a '''''prefix''''' tag - when using the macros in test code, the '''''prefix''''' should be replaced by one of the following: '''srEXPECT''', '''srASSERT''', or '''srEXIT''', depending on how the test writer wants failures to be handled.
@@ Line 89: / Line 78: @@
 srEXPECT_TRUE(1 < 2);
 srEXPECT_TRUE(1);
 </source>

Marku at 15:16, 1 July 2015

2015-07-01T15:16:25Z

← Older revision		Revision as of 15:16, 1 July 2015
Line 1:		Line 1:
	== Test Macros ==		__NOTOC__
			The Stride implementation of [http://en.wikipedia.org/wiki/Assertion_(software_development) assertions] are provided with a set of Test Macros (declared in srtest.h) available for use within test methods. The macros are optional - you are not required to use them in your '''Test Units''. They provide shortcuts for testing assertions and automatic report annotation in the case of failures.

	~~The STRIDE Test Unit implementation also provides a set of~~ Test Macros ~~(declared in srtest~~.h) available for use within test methods. The macros are optional - you are not required to use them in your test units. They provide shortcuts for testing assertions and automatic report annotation in the case of failures.		'''Example Test Macros'''
			<source lang=cpp>
			#include <mytest.h>

	== ~~General~~ Guidelines ~~for Test Macros~~ ==		void MyTest::CheckFoo() {
			..
			srEXPECT_EQ(foo(2 + 2), 4);
			}
			void MyTest::CheckBoo() {
			..
			srEXPECT_GT(boo(3 * 3), 7);
			}
			</source>


			== Guidelines ==

	There are four types of macros: '''EXPECT''', '''ASSERT''', '''EXIT''', and '''NOTE''' macros. They have slight but important differences in their behavior.		There are four types of macros: '''EXPECT''', '''ASSERT''', '''EXIT''', and '''NOTE''' macros. They have slight but important differences in their behavior.
Line 27:		Line 41:
	* If a teardown fixture is declared, and the srEXIT_xx() fires within a test method, the teardown method will be called.		* If a teardown fixture is declared, and the srEXIT_xx() fires within a test method, the teardown method will be called.
	* If srEXIT_xx() fires within a scl_test_cclass test unit, its de-init function will be called if declared.		* If srEXIT_xx() fires within a scl_test_cclass test unit, its de-init function will be called if declared.

	~~[[Test_Macros#Notes \| '''srNOTE('''''message''''')''' ]]~~
	* Unconditionally adds an annotation to the current test case's results report which includes the message as well as file and line number


Line 44:		Line 55:
	The ''srEXIT_xx()'' macro does not support this feature. For more information please read [[C%2B%2B_Only_Features\|this]].		The ''srEXIT_xx()'' macro does not support this feature. For more information please read [[C%2B%2B_Only_Features\|this]].

	~~== Assertions ==~~

	The following sections document the several types of testing macros that are provided by the STRIDE Framework. For simplicity, we refer to all the macros using a '''''prefix''''' tag - when using the macros in test code, the '''''prefix''''' should be replaced by one of the following: '''srEXPECT''', '''srASSERT''', or '''srEXIT''', depending on how the test writer wants failures to be handled.		The following sections document the several types of testing macros that are provided by the STRIDE Framework. For simplicity, we refer to all the macros using a '''''prefix''''' tag - when using the macros in test code, the '''''prefix''''' should be replaced by one of the following: '''srEXPECT''', '''srASSERT''', or '''srEXIT''', depending on how the test writer wants failures to be handled.

	=== Boolean Macros ===		== Boolean Macros ==
	The boolean macros take a single condition expression, ''cond'', that evaluates to an integral type or bool.		The boolean macros take a single condition expression, ''cond'', that evaluates to an integral type or bool.

Line 81:		Line 91:
	</source>		</source>

	=== Comparison Macros ===
			== Comparison Macros ==

	Comparison macros take two operands and compare them using the indicated operator.		Comparison macros take two operands and compare them using the indicated operator.
Line 129:		Line 140:
	srEXPECT_GE( 2 , 1 );		srEXPECT_GE( 2 , 1 );
	</source>		</source>
	=== C String Comparison Macros ===

			== C String Comparison Macros ==

	C String Comparison Macros are intended only for use with C-style null terminated strings. The strings can be char or wchar_t based.		C String Comparison Macros are intended only for use with C-style null terminated strings. The strings can be char or wchar_t based.
Line 178:		Line 191:


	=== Predicate Macros ===		== Predicate Macros ==
	Predicate macros allow user control over the pass/fail decision making.		Predicate macros allow user control over the pass/fail decision making.

Line 224:		Line 237:
	</source>		</source>

	=== Floating Point Comparison Macros ===
			== Floating Point Comparison Macros ==
	Floating point macros are for comparing equivalence (or near equivalence) of floating point numbers.		Floating point macros are for comparing equivalence (or near equivalence) of floating point numbers.

Line 253:		Line 267:
	</source>		</source>

	=== Exception Macros ===
			== Exception Macros ==
	Exception macros are used to ensure that expected exceptions are thrown. They are applicable to <u>C++ code only</u>.		Exception macros are used to ensure that expected exceptions are thrown. They are applicable to <u>C++ code only</u>.

Line 287:		Line 302:
	</source>		</source>

	=== Dynamic Test Case Macros ===
			== Dynamic Test Case Macros ==
	The macros presented so far assume that their actions are directed at the currenly in-scope test case. However, test cases can be created dynamically using STRIDE's [Runtime Test Services].		The macros presented so far assume that their actions are directed at the currenly in-scope test case. However, test cases can be created dynamically using STRIDE's [Runtime Test Services].

Line 370:		Line 386:

	\|}		\|}

	~~== Notes ==~~
	Note macros provide a simple means to add annotations attached to the currently executing test case. These annotations are added to the test report info with a level of either ''Error'', ''Warning'', or ''Info'' according to the macro that is used.

	~~{\| class="prettytable"~~
	~~\| colspan="2" \| '''Error Annotation'''~~
	\|-
	~~\| srNOTE_ERROR(''message'', ...)~~
	~~\| ''message'' is a pointer to a null-terminated format string<br/>~~
	~~''...'' variable list matching the format string~~
	\|}

	~~{\| class="prettytable"~~
	~~\| colspan="2" \| '''Warning Annotation'''~~
	\|-
	~~\| srNOTE_WARN(''message'', ...)~~
	~~\| ''message'' is a pointer to a null-terminated format string<br/>~~
	~~''...'' variable list matching the format string~~
	\|}

	~~{\| class="prettytable"~~
	~~\| colspan="2" \| '''Info Annotation'''~~
	\|-
	~~\| srNOTE_INFO(''message'', ...)~~
	~~\| ''message'' is a pointer to a null-terminated format string<br/>~~
	~~''...'' variable list matching the format string~~
	\|}

	* versions of these log macros also exist for use with dynamically generated test cases. To use these macros, just append '''_DYN''' to the macro names shown above and then pass the explicit ''testCaseHandle_t'' item as the first argument to the macros.
	* The maximum length of the message string approximately 1000 characters. If the maximum length is exceeded, the message string is truncated.

	~~=== Example ===~~
	~~<source lang='c'>~~
	~~srNOTE_ERROR("This is an error message.");~~
	~~srNOTE_WARN("This is a warning message with format string %d.", 123);~~
	~~srNOTE_INFO("This is an info message with format string %s and %s.", "this", "that");~~
	~~</source>~~


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

Ivailop: /* Notes */

2014-09-11T18:09:21Z

Notes

← Older revision		Revision as of 18:09, 11 September 2014
Line 377:		Line 377:
	\| colspan="2" \| '''Error Annotation'''		\| colspan="2" \| '''Error Annotation'''
	\|-		\|-
	\| srNOTE_ERROR~~(''message'')~~		\| srNOTE_ERROR(''message'', ...)
	~~\| ''message'' is a pointer to a null-terminated string~~
	\|-
	~~\| srNOTE[1..9]_ERROR~~(''message'', ...)
	\| ''message'' is a pointer to a null-terminated format string<br/>		\| ''message'' is a pointer to a null-terminated format string<br/>
	''...'' variable list ~~(up to 9)~~ matching the format string		''...'' variable list matching the format string
	\|}		\|}

Line 388:		Line 385:
	\| colspan="2" \| '''Warning Annotation'''		\| colspan="2" \| '''Warning Annotation'''
	\|-		\|-
	\| srNOTE_WARN~~(''message'')~~		\| srNOTE_WARN(''message'', ...)
	~~\| ''message'' is a pointer to a null-terminated string~~
	\|-
	~~\| srNOTE[1..9]_WARN~~(''message'', ...)
	\| ''message'' is a pointer to a null-terminated format string<br/>		\| ''message'' is a pointer to a null-terminated format string<br/>
	''...'' variable list ~~(up to 9)~~ matching the format string		''...'' variable list matching the format string
	\|}		\|}

Line 399:		Line 393:
	\| colspan="2" \| '''Info Annotation'''		\| colspan="2" \| '''Info Annotation'''
	\|-		\|-
	\| srNOTE_INFO~~(''message'')~~		\| srNOTE_INFO(''message'', ...)
	~~\| ''message'' is a pointer to a null-terminated string~~
	\|-
	~~\| srNOTE[1..9]_INFO~~(''message'', ...)
	\| ''message'' is a pointer to a null-terminated format string<br/>		\| ''message'' is a pointer to a null-terminated format string<br/>
	''...'' variable list ~~(up to 9)~~ matching the format string		''...'' variable list matching the format string
	\|}		\|}

Line 413:		Line 404:
	<source lang='c'>		<source lang='c'>
	srNOTE_ERROR("This is an error message.");		srNOTE_ERROR("This is an error message.");
	~~srNOTE1_WARN~~("This is a warning message with format string %d.", 123);		srNOTE_WARN("This is a warning message with format string %d.", 123);
	~~srNOTE2_INFO~~("This is an info message with format string %s and %s.", "this", "that");		srNOTE_INFO("This is an info message with format string %s and %s.", "this", "that");
	</source>		</source>


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

Ivailop: /* General Guidelines for Test Macros */

2014-01-29T23:53:40Z

General Guidelines for Test Macros

← Older revision		Revision as of 23:53, 29 January 2014
Line 34:		Line 34:
	''' ''Hint:'' A simple way to add supplemental information to test failures'''		''' ''Hint:'' A simple way to add supplemental information to test failures'''

	If the '''c++ compiler mode''' is enabled then the ''srEXPECT_xx()'' and ''srASSERT_xx()'' macros also support adding to a test's annotations using the '''<< operator'''. For example:		If the '''C++ compiler mode''' is enabled then the ''srEXPECT_xx()'' and ''srASSERT_xx()'' macros also support adding to a test's annotations using the '''<< operator'''. For example:

	<source lang="cpp">		<source lang="cpp">

← Older revision		Revision as of 22:25, 29 September 2015
Line 22:		Line 22:

	'''srEXPECT_''xx''('''''condition''''')'''		'''srEXPECT_''xx''('''''condition''''')'''
	* If the condition <u>does</u> match the expectation, this macro:
	** sets the current test case status to PASS
	* If the condition <u>does not</u> match the expectation, this macro:		* If the condition <u>does not</u> match the expectation, this macro:
	** sets the current test case status to FAIL		** sets the current test case status to FAIL
	** adds ~~a comment~~ to the current test case's results report which includes the condition as well as file and line number		** adds an "error" annotation to the current test case's results report which includes the condition as well as file and line number
	** does not alter code execution		** does not alter code execution

	'''srASSERT_''xx''('''''condition''''')'''		'''srASSERT_''xx''('''''condition''''')'''
	* If the condition <u>does</u> match the assertion, this macro:
	** sets the current test case status to PASS
	* If the condition <u>does not</u> match the expectation, this macro:		* If the condition <u>does not</u> match the expectation, this macro:
	** sets the current test case status to FAIL		** sets the current test case status to FAIL
	** adds ~~a comment~~ to the current test case's results report which includes the condition as well as file and line number		** adds an "error" annotation to the current test case's results report which includes the condition as well as file and line number
	** <u>immediately returns</u> from the current test function. The return specifies no value, therefore a function or method that uses <tt>srASSERT_xx</tt> <u>should be declared to return <tt>void</tt></u>. <i>In case when a test function is required to return other type then <tt>void</tt>, a simple trick could be applied - in <b>C++ test code</b> postpend any value of the required type using the <u>C/C++ <tt>comma</tt> operator</u> (e.g. <tt>srASSERT_TRUE(cond),1;</tt>); in <b>C only test code</b> postpend the value <u>space</u> separated (e.g. <tt>srASSERT_TRUE(cond) 1;</tt>).</i>		** <u>immediately returns</u> from the current test function. The return specifies no value, therefore a function or method that uses <tt>srASSERT_xx</tt> <u>should be declared to return <tt>void</tt></u>. <i>In case when a test function is required to return other type then <tt>void</tt>, a simple trick could be applied - in <b>C++ test code</b> postpend any value of the required type using the <u>C/C++ <tt>comma</tt> operator</u> (e.g. <tt>srASSERT_TRUE(cond),1;</tt>); in <b>C only test code</b> postpend the value <u>space</u> separated (e.g. <tt>srASSERT_TRUE(cond) 1;</tt>).</i>