State Interface Test

We'll create a simple test to verify some of the behavior of the State interface, provided in the tinyos-2.x baseline by the State component (tinyos-2.x/tos/system/StateC.nc). Here's a look at the State interface:

 tinyos-2.x/tos/interfaces/State.nc
 
 interface State {
 
   /**
    * This will allow a state change so long as the current
    * state is S_IDLE.
    * @return SUCCESS if the state is change, FAIL if it isn't
    */
   async command error_t requestState(uint8_t reqState);
   
   /**
    * Force the state machine to go into a certain state,
    * regardless of the current state it's in.
    */
   async command void forceState(uint8_t reqState);
   
   /**
    * Set the current state back to S_IDLE
    */
   async command void toIdle();
   
   /**
    * @return TRUE if the state machine is in S_IDLE
    */
   async command bool isIdle();
   
   /**
    * @return TRUE if the state machine is in the given state
    */
   async command bool isState(uint8_t myState);
   
   /**
    * Get the current state
    */
   async command uint8_t getState();
 
 }

Setup

First we create a directory to store the State test. Although there is already a TestStateC directory in the TUnit repository, we'll create a new and separate directory to house our own test.

The State component and interface is in the TinyOS baseline. Therefore, we'll put the test under the tinyos-2.x baseline tests (tunit/tests/tinyos-2.x). The State component in the baseline exists in the tinyos-2.x/tos/system directory, so the test directory should follow a parallel mapping. Let's call the test something like TestStateComponent to be descriptive.

 tinyos-2.x-contrib/tunit/tests/
 |-- tinyos-2.x
 |   |-- tos
 |   |   |-- system
 |   |   |   |-- TestStateComponent

 TUnit Tip
 Start all test names and directories with the word Test for consistency.