|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 3 of 4
easyb is comparable to other executable documentation tools, such as Fit, Fitnesse, and Green Pepper, in that each provides the capability to capture system behaviors in order to communicate intent and bind these expectations to the system under test. But easyb stands out among these tools because its syntax really stays out of the way during the specification-writing process. Its concise, clutter-free specification-writing domain language frees the specification writer from distracting syntax, leaving the focus instead on the conversation and the system behaviors.
Consider again the frequent flyer rewards system you peeked at earlier. Throughout the development process, team members will
sit down with domain experts to explore and capture system requirements. easyb facilitates the capture of these behaviors
in the form of user stories. easyb provides support for user stories at two levels. First, a narrative description of the
story can be optionally expressed in the popular as_a, i_want, so_that form. easyb also allows zero or more scenarios to augment this narrative and various conditions to be included as well.
Listing 6 illustrates a simple story narrative written in easyb expressing how airline miles are accrued when a passenger flies a single segment.
narrative 'segment flown', {
as_a 'frequent flyer'
i_want 'to accrue rewards points for every segment I fly'
so_that 'I can receive free flights for my dedication to the airline'
}
The only elements of this document that are specific to easyb are the narrative, as_a, i_want, and so_that keywords, the quote marks, and the curly braces. This allows the conversation with the requirement donor to be more focused
on system behaviors and less distracted by syntax, a benefit easyb offers over the other tools mentioned above. (The underscores
in the keywords are an unfortunate consequence of how the easyb DSL is implemented as an extension to Groovy, and will be
resolved in easyb 1.0.) A narrative of this type can be very easily understood by non-programmers and is very quick to write.
This form of capturing a user story provides context around who benefits from an enhancement, and in what ways.
The narrative description of system behavior can be augmented with one or more scenarios that elaborate on the story description by providing concrete examples that are verifiable against the system. Listing 7 illustrates a scenario for the frequent flyer story narrative in Listing 6.
scenario segment flown', {
given 'a frequent flyer with a rewards balance of 1500 points'
when 'that flyer completes a segment worth 500 points'
then 'that flyer has a new rewards balance of 2000 points'
}
easyb also makes it easy to bind pending stories to the system under test. The scenario expressions can be augmented with closure blocks, allowing programmers to bind the specification to the system using whatever constructs the system's design supports. Because easyb specifications are Groovy scripts, any Groovy programming constructs can be used in this binding process.
For example, the segment flown scenario described in Listing 7 can be bound to the system under test as shown in Listing 8.
scenario 'segment flown', {
given 'a frequent flyer with a rewards balance of 1500 points', {
flyer = new FrequentFlyer(1500)
}
when 'that flyer completes a segment worth 500 points', {
flyer.fly(new Segment(500))
}
then 'that flyer has a new rewards balance of 2000 points', {
flyer.pointsBalance.shouldBe 2000
}
}
As a shared understanding grows between the developers and the product owner in the story-writing process, the act of binding these specifications to the system under test verifies this understanding and serves as a mechanism to determine if the system deviates from this expected behavior over time.
More about easyb
Related technologies and downloads
More