These three words bind a feature together with a means to verify it, because the words describe a flow or sequence of events:
Given some context,
When something happens,
Something else should happen.
2.
3.
In easyb, scenarios — not stories — have states. A scenario can be in a passing, failing, or pending state. Pending is handy because it can indicate that a particular scenario is actively being worked on. Failing, obviously, indicates an error condition either occurring in the application being verified or possibly in how the scenario is defined.
Scenarios in easyb define steps using the keywords given, when, then, and optionally and. Each keyword definition in a scenario looks a lot like the scenario keyword definition, as Listing 10 shows:
4.then
easyb supports a host of similar checks, including:
shouldNotBe
shouldEqual
shouldNotEqual
shouldBeGreaterThan
shouldBeLessThan
5.file extension
The stories in easyb should and must be in a file ending with an extension of .story. So our login story would be placed in a file called LoginServiceTest.story.
If you have a story named AccountServiceTest.groovy, you will get an exception as such:
Buildfile: /Users/meerasubbarao/Development/easyb-samples/build.xml init: run.easyb.stores: [easyb] easyb is preparing to process 2 file(s) [easyb] Easyb behavior file must end in Story.groovy, .story, Specification.groovy or .specification. See easyb documentation for more details. [easyb] easyb execution FAILED BUILD SUCCESSFUL Total time: 1 second