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 2 of 4

Introducing easyb

easyb is a BDD framework for the Java platform that makes it (you guessed it) easy to describe and verify system behaviors at all levels. With easyb, you can write user stories, develop specifications for system components, describe UI interactions, and much more. But easyb isn't the only BDD framework; you have many other options, including JBehave, JDave, and RSpec. So what is unique about easyb? Because of its implementation as a Groovy-based domain-specific language (DSL), easyb features a uniquely concise and highly expressive language for expressing behaviors.

easyb specifications are represented as Groovy scripts. Because of the nature of the Groovy language, and the leniency afforded to Groovy scripts over classes, easyb specifications are relatively free of programmer-specific syntax, placing the focus instead on communicating behaviors. For example, Listing 1 is a completely valid minimal expression of behavior for a frequent flyer rewards calculator represented as an easyb specification.

Listing 1. Behavior for a frequent flyer rewards calculator

it 'should calculate rewards points for a segment flown'

This type of specification, in which behavior is described but not actually bound to the system under test, is called a pending specification in easyb. Pending specifications are reported as pending by the easyb runner and are included in the story reports that easyb renders. This allows a team to create specifications at the beginning of a release or iteration and bind them to the system over time as features are implemented.

This description of behavior can be augmented by attaching code blocks that verify the behavior of the system under test, as shown in Listing 2.

Listing 2. Verifying behavior

it 'should calculate rewards points for a segment flown', {
     calculator = new RewardsCalculator()
     calculator.rewardsForSegmentWithDistance(750).shouldBe 750
 }

Listing 2 consists of three components: the it keyword, which identifies the block as a specification to be run by easyb; a string description of the specification, surrounded with quotes; and a closure block, in which Groovy code is written to bind the expressed behavior to the system under test. Notice also that the expanded version asserts the frequent flyer points that should be rewarded for flying a single segment using the shouldBe keyword. easyb's DSL provides a rich set of expressions that allow expectations to be conveyed in a very readable manner. The easyb DSL is documented in more detail online and includes constructs for testing equality, negation, containment, nullness, types, and exceptions.

The specification in Listing 2 can now be run; but because the spec was written before the code necessary to make it pass, the spec will fail, as the RewardsCalculator class does not exist. After writing the RewardCalculator class shown in Listing 3, re-running the spec will result in success.

Listing 3. Making the spec pass by writing code

public class RewardsCalculator {
    public int rewardsForSegmentWithDistance(int total) {
        if (total < 0)
            throw new IllegalArgumentException("Cannot fly negative miles");
        return total;
    }
}

Once the spec passes, you can begin to modify it as you add functionality to your application. For example, you can assert that a collection contains specific elements, as in Listing 4.

Listing 4. Requiring specific elements in a collection

it 'should return gold, platinum, and executive as types', {
     ensure (new EliteStatusRegistry().listTypes()) {
         contains('gold')
         and
         contains('platinum')
         and
         contains('executive')
     }
 }

Listing 5 demonstrates how to establish the ways in which exceptions are thrown.

Listing 5. An exception for the behavior

it 'should calculate the sales tax for a purchase', {
     calculator = new RewardsCalculator()
     ensureThrows(IllegalArgumentException.class) {
         calculator.rewardsForSegmentWithDistance(-1)
     }
 }

These examples illustrate how easyb can be used to test system behaviors at the unit or component level. In easyb parlance, these are simply referred to as specifications and use an it should syntax when describing behaviors. easyb can also be used to verify systemwide behaviors through the use of user stories.