Our Reactive Story Pub Share

A quick overview of stories... by telling the "lights" story. Stories stand in for user stories, scenarios, use cases, even test cases (like integration testing).

Stories are told in terms of some input messages and expected outcomes (messages and values).

The lights story

On one beautiful summer eve, a guest arrived arrived at our house, so let's send that message...

send::  msg home.guest_arrived  (name="Jane")

Two things must happen: the message to turn the lights on must have been sent and the lights must be bright, let's mention that we expect them...

expect::  lights.on

expect::  (light is "bright")

Testing

When a story is being "told" or executed, to be more precise, the input messages are executed and then the expectations are tested. A report is produced, showing the entire execution trace and test results:

In the fiddle, this is rendered continuously, as you write the story.

You could test for chimes to welcome the person and let's say the chimes say the wrong name...

In this case here's the test:

expect::  chimes.welcome (name is "Jane")

And the rule that generated it:

$when:: home.guest_arrived (name is "Jane")
   chimes.welcome (name="John"="John")

... and you can see the value sourcing was highlighted, making it easy to fix. You should try this out right now in the fiddle bellow, changing some values and trying to make the tests fail.

$send home.guest_arrived (name="Jane")
$expect lights.on
$expect (light is "bright")
$expect chimes.welcome(name is "Jane")

dsl here...

result...

Since these are ran continuously as you work on the stories, you have instant feedback. You don't have to wait for some developers to build the system, compile, dockerize and run only to find the problem - you know all issues upfront.

Wiki syntax

As you can see, this is a markdown wiki, which is becoming more and more common for quick content creation.