ReceiveEvent(ControlEvent.Command, null);
c.DispatchHandler(); // Calibrate
// Exit before Timeout scheduled by second CheckMessage
c.ReceiveEvent(ControlEvent.Exit, null);
Console.Write("\nDid the expected handlers run? [y/n] ");
string answer = Console.ReadLine();
Assert.IsTrue(answer[0] == ??™y??™ || answer[0] == ??™Y??™);
}
Figure 3.7. Test method for a typical controller run.
respond to the reset command ??“ the call to StartTimer ensures that a time-out event
will occur. This will enable the ReportLostMessage handler.
In a similar way, the other guards and handlers are all coded to work together,
to generate the behavior described in Section 3.1. To get the controller started,
the constructor of the Simulator application starts the timer, and the variables in
Controller are all initialized to enable the Reset handler when the time-out occurs.
3.3 Unit testing
The controller logic is intricate, so we suspect that it might be defective.We resolve
to do some testing to check our intuitions that the controller behaves as we intend.
We can test a reactive program in a sandbox that replaces observable events by
controllable events. In our controller, we can achieve this by calling the controller??™s
ReceiveEvent method directly from the test code, rather than invoking it from an
event handler.
Figure 3.7 shows an NUnit test method that checks the typical run where the
controller successfully resets, then polls, then computes the calibration factor.
Pages:
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79