Modeling Events

Frequently, a system under test (SUT) will emit events. Spec Explorer’s view is that an event is a message from the SUT to a test case at test execution time. Spec Explorer’s role is to construct the test case so that it can receive the event and act appropriately.

In order to correctly construct the test cases to receive events, Spec Explorer does indeed need to know what events can be raised. However, events from the SUT are NOT explicitly modeled in the model program; the Cord configuration is used to let Spec Explorer know that a given action is an event or a control.

Events and Cord

The following code snippets, taken from the PubSub sample distributed with the Spec Explorer software, shows how Spec Explorer interacts with events. The PubSub sample is a simple Publish/Subscribe program, with a Publisher and one or more Subscribers. Use Finding the Code Samples to locate the PubSub sample.

The general algorithm used by the PubSub sample is that a subscriber raises a Received event when it receives a message from the publisher. The following code, taken from the Implementation.cs file, shows the definition of the Received event. In this sample project, the Implementation.cs file contains the code for the system under test (SUT).

#region Subscriber

    public delegate void ReceivedEventHandler(string data);

    public class Subscriber
    {
        static int instanceCount;
        int count;

        public event ReceivedEventHandler Received;

        // code removed .....

        internal void RaiseReceived(string data)
        {
            if (Received != null)
                Received(data);           
        }
    }

    #endregion

The Received event is declared as an event in the base configuration in the Config.cord file, as follows:

config Config 
{
    action Publisher();
    action void Publisher.Publish(string data);
    action Subscriber(Publisher pub);
    action event void Subscriber.Received(string data);

    switch StepBound = 1024;
    switch StateBound = 1024;

    switch GeneratedTestPath = "..\\TestSuite";  
    switch TestClassBase = "vs";
    
    switch TestEnabled = false;
}

Now let’s take a look at the model program, Model.cs. Note that there is no explicit model for the Received event; rather, the Subscriber.Received method in the model program simply performs the tasks necessary to move to the next state in the exploration.

#region Subscriber

    [TypeBinding("PubSub.Implementation.Subscriber")]
    public class Subscriber
    {
        // code removed.....
        [Rule(Action = "this.Received(data)")]
        public void Received(string data)
        {
            Condition.IsTrue(messages.Count > 0);
            Condition.IsTrue(messages[0] == data);
            messages.RemoveAt(0);
        }
               
    }
    #endregion

Events and Testing

During testing, Spec Explorer is matching expected SUT outputs to the model. In this example, since Subscriber.Received is an event, Spec Explorer will expect the SUT to raise the event and will construct the test cases to subscribe to the event.

See Also

Concepts

Testing and Events
Finding the Code Samples
Modeling Tips and Tricks

Other Resources

Modeling Toolbox