Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

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

Behavior-driven development with easyb

Groovy DSL lets developers and domain experts speak the same language

By Rod Coffin, JavaWorld.com, 09/04/08

Page 3 of 4

User stories

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.

Listing 6. A story expressing how airline miles are accrued

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.

Listing 7. A frequent flier scenario

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.

Listing 8. Binding a scenario to the system under test

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.