While events can be sent to an interpreter using its queue() method, it can be very convenient
to define and store scenarios, ie. sequences or traces of events, that can control the execution of a statechart.

Such scenarios are called stories in sismic, and can be used to accurately reproduce the execution of a statechart.
They are also very instrumental for testing statecharts.

The module sismic.stories provides the building bricks to automate statechart execution.
The key concept of this module is the notion of story, which is a reproducible sequence of
events and pauses that control a statechart interpreter.
For our running elevator example, a story may encode things like “first select the 4th floor, then
wait 5 seconds, then select the 2th floor, then wait for another 10 seconds”.
This would look as follows:

A instance of Story exhibits a tell()
method that can tell the story to an interpreter. Using this method, you can easily reproduce
a scenario.

# ... (assume that some interpreter has been created for our elevator statechart)assertisinstance(interpreter,Interpreter)story.tell(interpreter)print(interpreter.time,interpreter.context.get('current'))

After having told the story to the interpreter, we observe that 15 seconds have passed, and the elevator has moved to the ground floor.

15 0

While telling a whole story at once can be convenient, it is sometimes interesting to tell the story step by step.
The tell_by_step() returns a generator that yields the object (either a pause or an event)
that was told to the interpreter, and the result of calling execute().