Expectations Sample - Revision history

Marku: /* Introduction */

2012-06-22T16:06:40Z

Introduction

← Older revision		Revision as of 16:06, 22 June 2012
Line 3:		Line 3:

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

			Note - the following additional (non-standard) Perl package is required to run this Sample on Linux:
			* [http://search.cpan.org/~makamaka/JSON-2.53/lib/JSON.pm JSON]

			For more information on install non-standard packages refer [[Desktop_Installation#Linux \| here]].

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

Ivailop: /* Observations */

2011-06-09T19:12:04Z

Observations

← Older revision		Revision as of 19:12, 9 June 2011
Line 182:		Line 182:

	* there is a single suite called '''s2_expectations_module'''. This matches the name given to the test module.		* there is a single suite called '''s2_expectations_module'''. This matches the name given to the test module.
			* the test module's suite has one annotation - the source code of the test itself. This can be useful for quickly inspecting the code that was used to run the test without having to go to your actual test module implementation file.
	* the test module suite contains 14 test cases -- each one corresponds to a single test case (test function) in the module. The description for each test module was automatically generated from the POD documentation that was included in the test module file.		* the test module suite contains 14 test cases -- each one corresponds to a single test case (test function) in the module. The description for each test module was automatically generated from the POD documentation that was included in the test module file.
	* each test case has a list of several annotations~~. The first is a simple HTML view of the source code of the test itself. This can be useful for quickly inspecting the code~~ that ~~was used to run the test without having to go to your actual test module implementation file. The remaining annotation~~ contain information about each test point that was hit during processing and any expectation failures or timeouts that were encountered.		* each test case has a list of several annotations that contain information about each test point that was hit during processing and any expectation failures or timeouts that were encountered.


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

Ivailop: /* Observations */

2011-06-09T19:09:00Z

Observations

← Older revision		Revision as of 19:09, 9 June 2011
Line 182:		Line 182:

	* there is a single suite called '''s2_expectations_module'''. This matches the name given to the test module.		* there is a single suite called '''s2_expectations_module'''. This matches the name given to the test module.
	* the test module's suite has one annotation - it is a trace file containing all of the test points and logs that were reported to the host during the execution of the test module. This trace file can be useful if you want to get a sequential view of all test points that were encountered during the execution of the module.
	* the test module suite contains 14 test cases -- each one corresponds to a single test case (test function) in the module. The description for each test module was automatically generated from the POD documentation that was included in the test module file.		* the test module suite contains 14 test cases -- each one corresponds to a single test case (test function) in the module. The description for each test module was automatically generated from the POD documentation that was included in the test module file.
	* each test case has a list of several annotations. The first is a simple HTML view of the source code of the test itself. This can be useful for quickly inspecting the code that was used to run the test without having to go to your actual test module implementation file. The remaining annotation contain information about each test point that was hit during processing and any expectation failures or timeouts that were encountered.		* each test case has a list of several annotations. The first is a simple HTML view of the source code of the test itself. This can be useful for quickly inspecting the code that was used to run the test without having to go to your actual test module implementation file. The remaining annotation contain information about each test point that was hit during processing and any expectation failures or timeouts that were encountered.

Marku at 17:45, 9 June 2011

2011-06-09T17:45:28Z

@@ Line 166: / Line 166: @@
 each handler will have access to the stream of events as they happen during
 processing.
 [[Category:Samples]]

Mikee: /* Tests Description */

2010-07-13T23:06:03Z

Tests Description

← Older revision		Revision as of 23:06, 13 July 2010
Line 146:		Line 146:
	==== predicate_validation ====		==== predicate_validation ====
	This test shows that you can use a custom predicate along with		This test shows that you can use a custom predicate along with
	'''~~TEST_POINT_EVERYTHING~~'''. In this way, you can force all validation		'''TEST_POINT_ANY_AT_ALL'''. In this way, you can force all validation
	to be handled in your predicate. The predicate should return		to be handled in your predicate. The predicate should return
	0 to fail the test, 1 to pass the test, or '''TEST_POINT_IGNORE''' to		0 to fail the test, 1 to pass the test, or '''TEST_POINT_IGNORE''' to
Line 153:		Line 153:
	This technique should only be used in cases where the other		This technique should only be used in cases where the other
	more explicit expectation list techniques are not sufficient.		more explicit expectation list techniques are not sufficient.

			==== multiple_handlers ====

			This is test shows how you can use multiple test point setups simultaneously with each
			processing a different set of expectations. This can be a powerful technique and
			often produces more understandable test scenarios, particularly when you decompose
			your expetations down into small, easy to digest expectation lists.

			In this specific case, we create one handler that expects START and END, in
			sequence and another that just verifies that the IDLE event happens twice. We
			deliberately create both handlers before starting the processing so that
			each handler will have access to the stream of events as they happen during
			processing.

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

Ivailop: /* predicate_validation */

2010-05-17T22:01:50Z

predicate_validation

← Older revision		Revision as of 22:01, 17 May 2010
Line 154:		Line 154:
	more explicit expectation list techniques are not sufficient.		more explicit expectation list techniques are not sufficient.

	~~[[Category:The Sandbox]]~~
	[[Category:Samples]]		[[Category:Samples]]

Mikee at 18:17, 3 May 2010

2010-05-03T18:17:27Z

Show changes

Mikee at 00:52, 24 February 2010

2010-02-24T00:52:28Z

← Older revision		Revision as of 00:52, 24 February 2010
Line 7:		Line 7:

	=== <tt>s2_expectations_source.c / h</tt> ===		=== <tt>s2_expectations_source.c / h</tt> ===
	These files implement a simple state machine that we wish to test. The state machine runs when '''~~DoStateChanges~~''' is executed, which is a function we have also instrumented so it can be remotely invoked from the host.		These files implement a simple state machine that we wish to test. The state machine runs when '''Exp_DoStateChanges''' is executed, which is a function we have also instrumented so it can be remotely invoked from the host.

	The expected state transitions are as follows:		The expected state transitions are as follows:
Line 27:		Line 27:
	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:
	# call '''TestPointSetup''' with order parameter as well as expected and unexpected lists.		# call '''TestPointSetup''' with order parameter as well as expected and unexpected lists.
	# Invoke target processing by calling the remote function '''~~DoStateChanges~~'''.		# Invoke target processing by calling the remote function '''Exp_DoStateChanges'''.
	# use '''Check''' or '''Wait''' on the test point object to process the expectations.		# use '''Check''' or '''Wait''' on the test point object to process the expectations.

Line 70:		Line 70:

	This test is identical to the ''trace_data'' test except that a custom predicate is specified for the data validation. The custom predicate in this example just validates binary data using the standard memory comparison and implicitly passes for any non-binary payloads.		This test is identical to the ''trace_data'' test except that a custom predicate is specified for the data validation. The custom predicate in this example just validates binary data using the standard memory comparison and implicitly passes for any non-binary payloads.

			==== json_data ====

			This test demonstrates the use of [http://www.json.org JSON] formatted string data from the target in
			predicate validation. The string payload for the test point is decoded using the standard perl JSON library and the object's fields are validated in the predicate function above. JSON is a logical choice if you want to serialize small amounts of data in a platform agnostic way since it is widely supported in many languages.

	[[Category:The Sandbox]]		[[Category:The Sandbox]]
	[[Category:Samples]]		[[Category:Samples]]

Mikee at 21:05, 11 February 2010

2010-02-11T21:05:18Z

← Older revision		Revision as of 21:05, 11 February 2010
Line 62:		Line 62:
	take into account byte ordering for basic types. Here we assume the target has the same byte		take into account byte ordering for basic types. Here we assume the target has the same byte
	ordering as the host.		ordering as the host.

			==== trace_data ====

			This test is similar to sync_exact, except the expectations are loaded from a trace data file that was created using the <tt>--trace</tt> option on the [[STRIDE Runner]]. By default, tests that use a trace data file perform validation based on both the test point lable AND the data values in the trace file.

			==== trace_data_predicate ====

			This test is identical to the ''trace_data'' test except that a custom predicate is specified for the data validation. The custom predicate in this example just validates binary data using the standard memory comparison and implicitly passes for any non-binary payloads.

	[[Category:The Sandbox]]		[[Category:The Sandbox]]
	[[Category:Samples]]		[[Category:Samples]]

Marku: /* check_data */

2010-02-02T23:27:26Z

check_data

← Older revision		Revision as of 23:27, 2 February 2010
Line 63:		Line 63:
	ordering as the host.		ordering as the host.

			[[Category:The Sandbox]]
	[[Category:Samples]]		[[Category:Samples]]