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).
On one beautiful summer eve, a guest arrived arrived at our house, so let's send that message...
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...
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:
And the rule that generated it:
... 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 (light is "bright")
$expect chimes.welcome(name is "Jane")
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.
As you can see, this is a markdown wiki, which is becoming more and more common for quick content creation.