Difference between revisions of "Test Point Sample"

From STRIDE Wiki
Jump to: navigation, search
Line 1: Line 1:
=== StateController.c ===
+
The Test Point samples 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 file impelements 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.
+
 
 +
 +
=== StateController.c / h ===
 +
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.
 +
 
 +
The expected state transitions are as follows:
 +
 
 +
<pre>
 +
eSTART -> eIDLE -> eACTIVE -> eIDLE -> eEND
 +
</pre>
 +
 
 +
The states don't do any work; instead they just sleep() so there's some time spent in each one.
 +
 
 +
Each state transition is managed through a call to SetNewState() which communicates the state transition to the test thread using the srTEST_POINT() macro. We set the macro argument to the name of the state we are transitioning to as this is the 'value' of the testpoint that will be received by the test thread.
  
 
=== SequenceTest.h ===
 
=== SequenceTest.h ===

Revision as of 17:30, 26 March 2009

The Test Point samples 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.


StateController.c / h

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.

The expected state transitions are as follows:

eSTART -> eIDLE -> eACTIVE -> eIDLE -> eEND

The states don't do any work; instead they just sleep() so there's some time spent in each one.

Each state transition is managed through a call to SetNewState() which communicates the state transition to the test thread using the srTEST_POINT() macro. We set the macro argument to the name of the state we are transitioning to as this is the 'value' of the testpoint that will be received by the test thread.

SequenceTest.h

This file defines a class--SequenceTest--that is specified as a STRIDE test class using the *scl_test_class()* pragma.

SequenceTest derives from stride::srTest and thus inherits the test functionality implemented in this class.

SequenceTest.cpp

This file implements three tests of the state machine implemented in StateController.c. These tests demonstrate the use of the *srTestPointExpect()* macro to verify activity in another thread.

As the macro name suggests, 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.

ExactTest

LooseTest

TimeoutTest