Test Point Testing in C/C++ - Revision history

Jeffs: Replace STRIDE with Stride

2015-07-08T21:14:08Z

Replace STRIDE with Stride

Marku at 20:33, 6 July 2015

2015-07-06T20:33:01Z

← Older revision		Revision as of 20:33, 6 July 2015
Line 209:		Line 209:
	* All test points hit during the wait (both expected and unexpected) are added to the test report as testcase comments		* All test points hit during the wait (both expected and unexpected) are added to the test report as testcase comments
	* Once the wait is over (whether the expectation set has been satisfied or there has been a test failure), the current expectation set is automatically unregistered from the STRIDE runtime and the handle is released		* Once the wait is over (whether the expectation set has been satisfied or there has been a test failure), the current expectation set is automatically unregistered from the STRIDE runtime and the handle is released
	* If you want to return immediately from a test case if expectation fails then make the check/wait call an argument to ~~<tt>[[Test_Code_Macros#Assertions\|~~srASSERT_TRUE()~~]]</tt>~~.		* If you want to return immediately from a test case if expectation fails then make the check/wait call an argument to the ''srASSERT_TRUE()'' macro.

	==== srTestPointCheck ====		==== srTestPointCheck ====
Line 239:		Line 239:
	* All test points hit before the check (both expected and unexpected) are added to the test report as testcase comments		* All test points hit before the check (both expected and unexpected) are added to the test report as testcase comments
	* Once the check is done (whether the expectation set has been satisfied or there has been a test failure), the current expectation set is automatically unregistered from the STRIDE runtime and the handle is released		* Once the check is done (whether the expectation set has been satisfied or there has been a test failure), the current expectation set is automatically unregistered from the STRIDE runtime and the handle is released
	* If you want to return immediately from a test case if expectation fails then make the check/wait call an argument to ~~<tt>[[Test_Code_Macros#Assertions\|~~srASSERT_TRUE()~~]]</tt>~~.		* If you want to return immediately from a test case if expectation fails then make the check/wait call an argument to the ''srASSERT_TRUE()'' macro.

	=== C++ Facade Class ===		=== C++ Facade Class ===

Marku at 17:59, 2 July 2015

2015-07-02T17:59:13Z

← Older revision		Revision as of 17:59, 2 July 2015
Line 1:		Line 1:
	~~== Introduction ==~~		__NOTOC__
	Test Point [[Expectations]] tests can be written in native code (C/C++) and executed on the device under test using the STRIDE framework. In some cases, creating tests that run on the device itself might be preferable to host/script based tests, particularly if dealing with complex binary data payloads from test points.

	~~== Instrumenting Source Code ==~~
	Before any useful tests can be written, the source under test must be strategically instrumented with STRIDE Test Point macros. See [[Test_Point\|this article]] for information on how to accomplish that.

	~~== Creating Test Point Tests ==~~
	Test code to validate the [[Expectations]] of the Test Points often follows this basic pattern:		Test code to validate the [[Expectations]] of the Test Points often follows this basic pattern:

Line 48:		Line 42:
	#endif		#endif
	</source>		</source>


	== Reference ==		== Reference ==
Line 252:		Line 247:
	; Wait : instance method that provides same functionality as [[#srTestPointWait\|srTestPointWait]].		; Wait : instance method that provides same functionality as [[#srTestPointWait\|srTestPointWait]].
	; Check : instance method that provides same functionality as [[#srTestPointCheck\|srTestPointCheck]].		; Check : instance method that provides same functionality as [[#srTestPointCheck\|srTestPointCheck]].


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

Timd: /* srTestPointSetup */

2011-10-24T18:11:24Z

srTestPointSetup

← Older revision		Revision as of 18:11, 24 October 2011
Line 159:		Line 159:
	srTEST_POINT_EXPECT_ORDERED - the test points are expected to be hit exactly in the defined order <br/>		srTEST_POINT_EXPECT_ORDERED - the test points are expected to be hit exactly in the defined order <br/>
	srTEST_POINT_EXPECT_UNORDERED - the test points could to be hit in any order <br/>		srTEST_POINT_EXPECT_UNORDERED - the test points could to be hit in any order <br/>
	srTEST_POINT_EXPECT_STRICT - the test points are expected to be hit exactly as specified <br/>		srTEST_POINT_EXPECT_STRICT - the test points are expected to be hit exactly as specified (no consecutive duplicate hits)<br/>
	srTEST_POINT_EXPECT_NONSTRICT - other test points from the universe could to be hit in between <br/>		srTEST_POINT_EXPECT_NONSTRICT - other test points from the universe could to be hit in between <br/>
	srTEST_POINT_EXPECT_CONTINUE - on successful expectation satisfaction continue processing until the wait timeout expires		srTEST_POINT_EXPECT_CONTINUE - on successful expectation satisfaction continue processing until the wait timeout expires

Ivailop: /* srTestPointPredicate_t */

2011-02-14T22:43:24Z

srTestPointPredicate_t

← Older revision		Revision as of 22:43, 14 February 2011
Line 99:		Line 99:

	<source lang="c">		<source lang="c">
	typedef srBYTE (srTestPointPredicate_t)(const srTestPoint_t ptTP, void* pvUser);		extern "C" typedef srBYTE (srTestPointPredicate_t)(const srTestPoint_t ptTP, void* pvUser);
	</source>		</source>

Ivailop: /* srTestPointWait */

2010-11-01T17:19:18Z

srTestPointWait

← Older revision		Revision as of 17:19, 1 November 2010
Line 211:		Line 211:

	'''NOTES:'''		'''NOTES:'''
	* The test thread blocks until either the expectation set is satisfied or the timeout elapses.		* The test thread blocks until either the expectation set is satisfied, unless srTEST_POINT_EXPECT_CONTINUE is specified on setup, or the timeout elapses.
	* All test points hit during the wait (both expected and unexpected) are added to the test report as testcase comments		* All test points hit during the wait (both expected and unexpected) are added to the test report as testcase comments
	* Once the wait is over (whether the expectation set has been satisfied or there has been a test failure), the current expectation set is automatically unregistered from the STRIDE runtime and the handle is released		* Once the wait is over (whether the expectation set has been satisfied or there has been a test failure), the current expectation set is automatically unregistered from the STRIDE runtime and the handle is released

Ivailop: /* srTestPointSetup */

2010-11-01T17:17:50Z

srTestPointSetup

← Older revision		Revision as of 17:17, 1 November 2010
Line 160:		Line 160:
	srTEST_POINT_EXPECT_UNORDERED - the test points could to be hit in any order <br/>		srTEST_POINT_EXPECT_UNORDERED - the test points could to be hit in any order <br/>
	srTEST_POINT_EXPECT_STRICT - the test points are expected to be hit exactly as specified <br/>		srTEST_POINT_EXPECT_STRICT - the test points are expected to be hit exactly as specified <br/>
	srTEST_POINT_EXPECT_NONSTRICT - other test points from the universe could to be hit in between		srTEST_POINT_EXPECT_NONSTRICT - other test points from the universe could to be hit in between <br/>
			srTEST_POINT_EXPECT_CONTINUE - on successful expectation satisfaction continue processing until the wait timeout expires
	\|-		\|-
	\| tTestCase		\| tTestCase

Ivailop: /* Expected Array */

2010-11-01T17:15:37Z

Expected Array

← Older revision		Revision as of 17:15, 1 November 2010
Line 78:		Line 78:
	* A ''predicate'' value 0 indicates that any associated data with a test point payload will be ignored.		* A ''predicate'' value 0 indicates that any associated data with a test point payload will be ignored.
	* A ''user'' value 0 indicates that there is no user data associated with this test point		* A ''user'' value 0 indicates that there is no user data associated with this test point
	* The ''label'' could be specified to ''any test point'' within the current expected set of test points by using the [[Expectations#Special_Processing\|special]] ~~srTEST_POINT_ANYTHING~~ symbolic ~~constant~~.		* The ''label'' could be specified to ''any test point'' within the current expected set of test points by using the [[Expectations#Special_Processing\|special]] srTEST_POINT_ANY_IN_SET or srTEST_POINT_ANY_AT_ALL symbolic constants.

	==== Unexpected Array ====		==== Unexpected Array ====

Marku: /* Expected Array */

2010-07-14T23:34:01Z

Expected Array

← Older revision		Revision as of 23:34, 14 July 2010
Line 76:		Line 76:
	* A ''count'' value of either 0 or 1 is interpreted as 1		* A ''count'' value of either 0 or 1 is interpreted as 1
	* The ''count'' could be set as "0 or more" by using the [[Expectations#Special_Processing\|special]] srTEST_POINT_ANY_COUNT symbolic constant		* The ''count'' could be set as "0 or more" by using the [[Expectations#Special_Processing\|special]] srTEST_POINT_ANY_COUNT symbolic constant
	* A ''predicate'' value 0 indicates that any associated with a test point payload will be ignored.		* A ''predicate'' value 0 indicates that any associated data with a test point payload will be ignored.
	* A ''user'' value 0 indicates that there is no user data associated with this test point		* A ''user'' value 0 indicates that there is no user data associated with this test point
	* The ''label'' could be specified to ''any test point'' within the current ~~universe~~ by using the [[Expectations#Special_Processing\|special]] srTEST_POINT_ANYTHING symbolic constant.		* The ''label'' could be specified to ''any test point'' within the current expected set of test points by using the [[Expectations#Special_Processing\|special]] srTEST_POINT_ANYTHING symbolic constant.

	==== Unexpected Array ====		==== Unexpected Array ====

Ivailop at 20:59, 14 July 2010

2010-07-14T20:59:41Z

Show changes

← Older revision		Revision as of 21:14, 8 July 2015
Line 3:		Line 3:

	# Specify an expectation set consisting of expected (i.e. the test points that are expected to be hit) and optionally unexpected (i.e. the test points that are not expected to be hit) test points		# Specify an expectation set consisting of expected (i.e. the test points that are expected to be hit) and optionally unexpected (i.e. the test points that are not expected to be hit) test points
	# Register the expectation set with the ~~STRIDE~~ runtime		# Register the expectation set with the Stride runtime
	# Invoke the software under test (causing instrumentation points to be hit). This may not be necessary if the instrumented software under test is constantly running).		# Invoke the software under test (causing instrumentation points to be hit). This may not be necessary if the instrumented software under test is constantly running).
	# Wait for the expectation set to be satisfied or a timeout to occur		# Wait for the expectation set to be satisfied or a timeout to occur
Line 27:		Line 27:
	{0}};		{0}};

	/* register the expectation set ~~with the STRIDE~~ */		/* register the expectation set*/
	srWORD handle;		srWORD handle;
	srTestPointSetup(expected, unexpected, srTEST_POINT_EXPECT_UNORDERED, srTEST_CASE_DEFAULT, &handle);		srTestPointSetup(expected, unexpected, srTEST_POINT_EXPECT_UNORDERED, srTEST_CASE_DEFAULT, &handle);
Line 120:		Line 120:

	'''NOTE:'''		'''NOTE:'''
	* As part of the standard ~~STRIDE~~ distribution there are three predefined function predicate helpers:		* As part of the standard Stride distribution there are three predefined function predicate helpers:
	** srTestPointMemCmp - byte comparison		** srTestPointMemCmp - byte comparison
	** srTestPointStrCmp - string case sensitive comparison		** srTestPointStrCmp - string case sensitive comparison
Line 208:		Line 208:
	* The test thread blocks until either the expectation set is satisfied, unless srTEST_POINT_EXPECT_CONTINUE is specified on setup, or the timeout elapses.		* The test thread blocks until either the expectation set is satisfied, unless srTEST_POINT_EXPECT_CONTINUE is specified on setup, or the timeout elapses.
	* All test points hit during the wait (both expected and unexpected) are added to the test report as testcase comments		* All test points hit during the wait (both expected and unexpected) are added to the test report as testcase comments
	* Once the wait is over (whether the expectation set has been satisfied or there has been a test failure), the current expectation set is automatically unregistered from the ~~STRIDE~~ runtime and the handle is released		* Once the wait is over (whether the expectation set has been satisfied or there has been a test failure), the current expectation set is automatically unregistered from the Stride runtime and the handle is released
	* If you want to return immediately from a test case if expectation fails then make the check/wait call an argument to the ''srASSERT_TRUE()'' macro.		* If you want to return immediately from a test case if expectation fails then make the check/wait call an argument to the ''srASSERT_TRUE()'' macro.

Line 238:		Line 238:
	'''NOTES:'''		'''NOTES:'''
	* All test points hit before the check (both expected and unexpected) are added to the test report as testcase comments		* All test points hit before the check (both expected and unexpected) are added to the test report as testcase comments
	* Once the check is done (whether the expectation set has been satisfied or there has been a test failure), the current expectation set is automatically unregistered from the ~~STRIDE~~ runtime and the handle is released		* Once the check is done (whether the expectation set has been satisfied or there has been a test failure), the current expectation set is automatically unregistered from the Stride runtime and the handle is released
	* If you want to return immediately from a test case if expectation fails then make the check/wait call an argument to the ''srASSERT_TRUE()'' macro.		* If you want to return immediately from a test case if expectation fails then make the check/wait call an argument to the ''srASSERT_TRUE()'' macro.

	=== C++ Facade Class ===		=== C++ Facade Class ===
	The ''srtest.h'' file provides a simple [http://en.wikipedia.org/wiki/Facade_pattern facade] class that wraps the test point APIs described above in a simple C++ class called '''srTestPointsHandler'''. If you are writing your unit tests in C++ (using ~~STRIDE~~ test classes), then this class is available for your use. The class implements the following methods, which correspond exactly to the C API equivalents:		The ''srtest.h'' file provides a simple [http://en.wikipedia.org/wiki/Facade_pattern facade] class that wraps the test point APIs described above in a simple C++ class called '''srTestPointsHandler'''. If you are writing your unit tests in C++ (using Stride test classes), then this class is available for your use. The class implements the following methods, which correspond exactly to the C API equivalents:

	; srTestPointsHandler : constructor. Takes four arguments which match exactly the first four parameters of the [[#srTestPointSetup\|srTestPointSetup]] function.		; srTestPointsHandler : constructor. Takes four arguments which match exactly the first four parameters of the [[#srTestPointSetup\|srTestPointSetup]] function.
	; Wait : instance method that provides same functionality as [[#srTestPointWait\|srTestPointWait]].		; Wait : instance method that provides same functionality as [[#srTestPointWait\|srTestPointWait]].
	; Check : instance method that provides same functionality as [[#srTestPointCheck\|srTestPointCheck]].		; Check : instance method that provides same functionality as [[#srTestPointCheck\|srTestPointCheck]].