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