Test Point Sample - Revision history

Marku: /* Observations */

2011-06-09T17:08:25Z

Observations

← Older revision		Revision as of 17:08, 9 June 2011
Line 78:		Line 78:

	The following are some test observations:		The following are some test observations:
			* the test point tests cases show the test points that were encountered, information about failures (if any) and log messages (the latter only because we included the --log_level=all option when executing the runner).
	* test point tests can be packaged into a harness using any of the [[Test_Units#Test_Units\|three types of test units]] that we support. In this case, we used an FList so that the sample could be used on systems that were not C++ capable.		* test point tests can be packaged into a harness using any of the [[Test_Units#Test_Units\|three types of test units]] that we support. In this case, we used an FList so that the sample could be used on systems that were not C++ capable.
	* one of two methods is used to process the test: [[Test_Point_Testing_in_C/C++#srTestPointWait\|srTestPointWait]] or [[Test_Point_Testing_in_C/C++#srTestPointCheck\|srTestPointCheck]]. The former is used to process test points as they happen (with a specified timeout) and the latter is used to process test points that have already occurred at the time it is called (post completion check).		* one of two methods is used to process the test: [[Test_Point_Testing_in_C/C++#srTestPointWait\|srTestPointWait]] or [[Test_Point_Testing_in_C/C++#srTestPointCheck\|srTestPointCheck]]. The former is used to process test points as they happen (with a specified timeout) and the latter is used to process test points that have already occurred at the time it is called (post completion check).

Marku at 17:01, 9 June 2011

2011-06-09T17:01:16Z

@@ Line 63: / Line 63: @@
 A structure is used as the test point payload, and a predicate is written to validate one or more fields
 in the resulting structure payload.
 [[Category:Samples]]

Marku: moved Test Point Samples to Test Point Sample

2011-06-06T23:50:36Z

moved Test Point Samples to Test Point Sample

← Older revision	Revision as of 23:50, 6 June 2011
(No difference)

Mikee: /* CheckData */

2010-02-24T21:16:38Z

CheckData

← Older revision		Revision as of 21:16, 24 February 2010
Line 54:		Line 54:

	==== CheckData ====		==== CheckData ====
	This test is identical to ~~the~~ SyncLooseTimed, except that we specify srTEST_POINT_EXPECT_ORDERED		This test is identical to SyncLooseTimed, except that we specify srTEST_POINT_EXPECT_ORDERED
	for an ordered expectation set '''and''' we specify expected data for some of our test points. This		for an ordered expectation set '''and''' we specify expected data for some of our test points. This
	test will pass only if the test points are seen in the specified order and match both the label		test will pass only if the test points are seen in the specified order and match both the label

Mikee at 21:16, 24 February 2010

2010-02-24T21:16:11Z

← Older revision		Revision as of 21:16, 24 February 2010
Line 35:		Line 35:
	The main difference between the tests is the values of the parameters provided to each test's validation API.		The main difference between the tests is the values of the parameters provided to each test's validation API.

	==== ~~TestPoint_SyncExact~~====		==== SyncExact====

	Here we verify an exact match between the contents of the ''expected'' array and the observed testpoints. The combination of ''srTEST_POINT_EXPECT_ORDERED'' and an ''unexpected list'' specifies that the test will pass only if:		Here we verify an exact match between the contents of the ''expected'' array and the observed testpoints. The combination of ''srTEST_POINT_EXPECT_ORDERED'' and an ''unexpected list'' specifies that the test will pass only if:
Line 41:		Line 41:
	* the testpoints are seen in the order specified		* the testpoints are seen in the order specified

	==== ~~TestPoint_SyncLooseTimed~~====		==== SyncLooseTimed====
	Here we loosen the restrictions of the exact test. By specifiying ''srTEST_POINT_EXPECT_UNORDERED'' and empty ''unexpected list'', we now will:		Here we loosen the restrictions of the exact test. By specifiying ''srTEST_POINT_EXPECT_UNORDERED'' and empty ''unexpected list'', we now will:
	* ignore any testpoints seen that aren't in the expected array. and		* ignore any testpoints seen that aren't in the expected array. and
Line 50:		Line 50:
	The srTestPointCheck() will now cause the test to fail only if all of the expected testpoints are not seen (the specified number of times) within the timeout period.		The srTestPointCheck() will now cause the test to fail only if all of the expected testpoints are not seen (the specified number of times) within the timeout period.

	==== ~~TestPoint_AsynLooseTimed~~====		==== AsyncLooseTimed====
	This test is identical to the SyncLooseTimed test, except that we call srTestPointWait() and pass a timeout value to 400 milliseconds, which will result in a test failure, as it takes approximately 600 milliseconds for the testpoint expectations to be satisfied.		This test is identical to the SyncLooseTimed test, except that we call srTestPointWait() and pass a timeout value to 400 milliseconds, which will result in a test failure, as it takes approximately 600 milliseconds for the testpoint expectations to be satisfied.

			==== CheckData ====
			This test is identical to the SyncLooseTimed, except that we specify srTEST_POINT_EXPECT_ORDERED
			for an ordered expectation set '''and''' we specify expected data for some of our test points. This
			test will pass only if the test points are seen in the specified order and match both the label
			and data specified.

			==== CheckBinaryData ====
			This test demonstrates the validation of a test point with a binary payload using a predicate function.
			A structure is used as the test point payload, and a predicate is written to validate one or more fields
			in the resulting structure payload.

	[[Category:Samples]]		[[Category:Samples]]

Ivailop: /* Tests Description */

2010-02-13T06:40:15Z

Tests Description

← Older revision		Revision as of 06:40, 13 February 2010
Line 23:		Line 23:
	=== s2_testpoint_basic ===		=== s2_testpoint_basic ===

	This example implements three tests of the state machine implemented in s2_testpoint_source. These tests demonstrate the use of ~~the~~ '''~~srTEST_POINT_WAIT~~()''' ~~macros~~ to verify activity in another thread and '''~~srTEST_POINT_CHECK~~()''' ~~macro~~ to verify an already completed activity.		This example implements three tests of the state machine implemented in s2_testpoint_source. These tests demonstrate the use of '''srTestPointWait()''' to verify activity in another thread and '''srTestPointCheck()''' to verify an already completed activity.

	Each test follows the same pattern in preparing and using the test point feature:		Each test follows the same pattern in preparing and using the test point feature:
	# specify the set of test points of interest - create an array of type '''srTestPointExpect_t''' which specifies the expected test points and optionally an array of type '''srTestPointUnexpect_t''' for unexpected		# specify the set of test points of interest - create an array of type '''srTestPointExpect_t''' which specifies the expected test points and optionally an array of type '''srTestPointUnexpect_t''' for unexpected
	# set the expectation array using '''~~srTestPointExpect~~()'''		# set the expectation array using '''srTestPointSetup()'''
	# start the state machine		# start the state machine
	# use '''~~srTEST_POINT_CHECK~~()''' or '''~~srTEST_POINT_WAIT~~()''' macro to validate the expected test points		# use '''srTestPointCheck()''' or '''srTestPointWait()''' macro to validate the expected test points

	We create an "expectation" of activity and then validate the observed activity against the expectation using rules that we specify. If the expectation is met, the test passes; if the expectation is not met, the test fails.		We create an "expectation" of activity and then validate the observed activity against the expectation using rules that we specify. If the expectation is met, the test passes; if the expectation is not met, the test fails.
Line 48:		Line 48:
	Note that the "IDLE" testpoint is now included in the expected array only once, but with an expected count of 2.		Note that the "IDLE" testpoint is now included in the expected array only once, but with an expected count of 2.

	The ~~srTEST_POINT_CHECK~~() will now cause the test to fail only if all of the expected testpoints are not seen (the specified number of times) within the timeout period.		The srTestPointCheck() will now cause the test to fail only if all of the expected testpoints are not seen (the specified number of times) within the timeout period.

	==== TestPoint_AsynLooseTimed====		==== TestPoint_AsynLooseTimed====
	This test is identical to the SyncLooseTimed test, except that we call ~~srTEST_POINT_WAIT~~() and pass a timeout value to 400 milliseconds, which will result in a test failure, as it takes approximately 600 milliseconds for the testpoint expectations to be satisfied.		This test is identical to the SyncLooseTimed test, except that we call srTestPointWait() and pass a timeout value to 400 milliseconds, which will result in a test failure, as it takes approximately 600 milliseconds for the testpoint expectations to be satisfied.

	[[Category:Samples]]		[[Category:Samples]]

Mikee at 19:34, 28 January 2010

2010-01-28T19:34:44Z

← Older revision		Revision as of 19:34, 28 January 2010
Line 2:		Line 2:
	This examples demonstrate a simple technique to monitor and test activity occurring in another thread. The samples show a common testing scenario of this type: where we want to verify the behavior of a state machine.		This examples demonstrate a simple technique to monitor and test activity occurring in another thread. The samples show a common testing scenario of this type: where we want to verify the behavior of a state machine.

	if you are not familiar with test points you may find it helpful to review the [[~~Using~~ Test ~~Points~~]] article before proceeding.		if you are not familiar with test points you may find it helpful to review the [[Test Point]] article before proceeding.

	== Source under test ==		== Source under test ==

Ivailop: /* TestPoint_SyncLooseTimed */

2009-12-23T19:16:01Z

TestPoint_SyncLooseTimed

← Older revision		Revision as of 19:16, 23 December 2009
Line 42:		Line 42:

	==== TestPoint_SyncLooseTimed====		==== TestPoint_SyncLooseTimed====
	Here we loosen the restrictions of the exact test. By specifiying ''srTEST_POINT_EXPECT_UNORDERED'' and empty ''unexpected list'' we now will:		Here we loosen the restrictions of the exact test. By specifiying ''srTEST_POINT_EXPECT_UNORDERED'' and empty ''unexpected list'', we now will:
	* ignore any testpoints seen that aren't in the expected array. and		* ignore any testpoints seen that aren't in the expected array. and
	* disregard the order in which the testpoints are received		* disregard the order in which the testpoints are received

Ivailop: /* s2_testpoint_basic */

2009-12-23T19:15:17Z

s2_testpoint_basic

Timd: /* s2_testpoint_source.c / h */

2009-06-12T23:08:13Z

s2_testpoint_source.c / h

← Older revision		Revision as of 23:08, 12 June 2009
Line 6:		Line 6:
	== Source under test ==		== Source under test ==

	=== s2_testpoint_source.c / h ===		=== <tt>s2_testpoint_source.c / h</tt> ===
	These files ~~impelement~~ a simple state machine that we wish to test. The state machine runs in its own thread, and starts when the thread function '''StateControllerTask''' is executed.		These files implement a simple state machine that we wish to test. The state machine runs in its own thread, and starts when the thread function '''StateControllerTask''' is executed.

	The expected state transitions are as follows:		The expected state transitions are as follows:

← Older revision		Revision as of 19:15, 23 December 2009
Line 26:		Line 26:

	Each test follows the same pattern in preparing and using the test point feature:		Each test follows the same pattern in preparing and using the test point feature:
	# create an array of type '''srTestPointExpect_t''' which specifies the expected test points		# specify the set of test points of interest - create an array of type '''srTestPointExpect_t''' which specifies the expected test points and optionally an array of type '''srTestPointUnexpect_t''' for unexpected
	# set the expectation array using '''srTestPointExpect()'''		# set the expectation array using '''srTestPointExpect()'''
	# start the state machine		# start the state machine
Line 33:		Line 33:
	We create an "expectation" of activity and then validate the observed activity against the expectation using rules that we specify. If the expectation is met, the test passes; if the expectation is not met, the test fails.		We create an "expectation" of activity and then validate the observed activity against the expectation using rules that we specify. If the expectation is met, the test passes; if the expectation is not met, the test fails.

	The main difference between the tests is the values of the parameters provided to each test's validation API.		The main difference between the tests is the values of the parameters provided to each test's validation API.

	==== TestPoint_SyncExact====		==== TestPoint_SyncExact====

	Here we verify an exact match between the contents of the ''expected'' array and the observed testpoints. The combination of srTEST_POINT_EXPECT_ORDERED and ~~srTEST_POINT_EXPECT_EXCLUSIVE~~ specifies that the test will pass only if:		Here we verify an exact match between the contents of the ''expected'' array and the observed testpoints. The combination of ''srTEST_POINT_EXPECT_ORDERED'' and an ''unexpected list'' specifies that the test will pass only if:
	* only the testpoints in the expected array are seen, and		* only the testpoints in the expected array are seen, and
	* the testpoints are seen in the order specified		* the testpoints are seen in the order specified

	==== TestPoint_SyncLooseTimed====		==== TestPoint_SyncLooseTimed====
	Here we loosen the restrictions of the exact test. By specifiying srTEST_POINT_EXPECT_UNORDERED and ~~srTEST_POINT_EXPECT_NONEXCLUSIVE,~~ we now will:		Here we loosen the restrictions of the exact test. By specifiying ''srTEST_POINT_EXPECT_UNORDERED'' and empty ''unexpected list'' we now will:
	* ignore any testpoints seen that aren't in the expected array. and		* ignore any testpoints seen that aren't in the expected array. and
	* disregard the order in which the testpoints are received		* disregard the order in which the testpoints are received