The Disco Blog Welcome Guest | Login or Register

The hip folks over at easyb.org have released version 0.8 of easyb. If you haven’t seen easyb yet, then you are in a for a real treat as easyb is the coolest thing since sliced bread, baby. As a BDD framework for the Java platform, easyb makes it super easy to craft executable documentation for software requirements by leveraging a flexible (and easy) story based domain specific language.

What’s particularly copasetic about the 0.8 release is the inclusion of a new IntelliJ plug-in, which makes working with easyb, well, even easier (if that’s possible, man). Many thanks to Rod Coffin for his hard work on this and the Maven 2 plug-in!

The DSL has been refined slightly to permit adding a description phrase (way to go Rodrigo Urubatan!); plus, because it’s everyone’s bag, you can chain phrases via and now– the DSL now permits a second repeated phrase substitute and instead as follows:

scenario "text",{
 given "text", {}
 and "given text", {}
 when "text", {}
 then "text", {}
 and "then text", {}
}

Abstract stories are now possible; thus, the proceeding closure to any phrase is now optional– easyb will make the story as pending. Kudos to Ken Brooks for this and the vast reporting improvements!

Other noteworthy changes:

• HTML story report generation via the Maven 2 plugin
• Groovy 1.5.4 compatible
• Numerous reporting improvements
• shouldNotHave
• bug fixes like exception catching
• naming clarifications

If you haven’t had a chance to check out easyb, then start lookin’ baby! See the mailing list or be a copasetic disco dancer and just download it!

The hip folks involved with easyb just released version 0.7! The latest and greatest version includes the new should wiring to all objects (i.e. value.shouldBe false) within the context of story (or behavior); moreover, easyb now offers Maven 2 support via a new plug-in.

What’s more, easyb.org has been updated to include documentation on the database plug-in, how to use the Maven 2 plug-in, and an in-depth description of the easyb should syntax. Plus, there is a new mailing list.

I had the pleasure of a buzz session with my hip friend Scott Davis recently regarding Groovy and the upcoming Groovy/Grails Experience. Scott is a entertaining guy to chat with and I had a lot of fun describing BDD with easyb and the joy of using Gant. Check out the hip podcast if you have a few spare minutes and don’t forget to show up to the conference later this month, baby!

I had the pleasure of being interviewed by Steven Devijver (of Grails fame) regarding easyb recently on the DZone– the title of the interview is dubbed “easyb: Introducing Conversational Unit Tests for Java.” I hadn’t thought about the term conversational when it comes to testing, but I think its right on, man! As the interview points out, with easyb, you can have conversational expectations that read quite nicely, such as

var.shouldNotBe null
and
var.length().shouldEqual 6 

If that code isn’t having a heart-to-heart with you regarding what var or its length should or should not be then I don’t know how to talk to you anymore, man.

Thanks, Steven, for the opportunity!

If chewing the fat over TDD and arm wrestling over whose CI server is better happens to be your idea of a good time, then you, baby, are in luck!! This year’s copasetic North American Continuous Integration and Testing Conference is going to be in Denver on April 4th and 5th and promises to bring together a band of hip individuals focused on topics like:

• what is the one true language for testing?
• what does the future hold for build languages?
• is Disco the greatest musical genre ever to grace the airwaves?
• what does CI 2.0 look like?
• do the people who practice BDD actually make more money?
• will Jeffrey Frederick have long or short hair this time?

If an all out brawl over BDD versus TDD is your bag or a cage match between CI vendors is your idea of entertainment, then stop drooling and sign up today, man! I’ll see you there!

The easyb code base has been moved to Google code, which has copasetic support for anonymous SVN access (which, unfortunately, didn’t work for QualityLabs). If you want to take a peek at what’s under the hood, simply type:

svn checkout http://easyb.googlecode.com/svn/trunk/ easyb-read-only

We’ve also created a hip easyb users group, so if you have any questions, comments, or rants, drop us a note!

The Framework for Integrated Tests serves as an copasetic mechanism for bridging the gap between those that write requirements and those that turn those requirements into code– the beauty of defining business rules in tabular format (either through HTML, Word documents, and even Excel files) and auto-magically wiring that data with application code is no Siren song, but an accelerating force for high speed development teams living in the Age of Aquarius. What’s more, combining FIT with a wiki was a brilliant move and the resulting tool, FitNesse, brings together the power of FIT with a collaborative mechanism for building test suites and capturing requirements (and even stories) by leveraging the ubiquity of a browser.

While FitNesse has been leveraged by some, it, in many ways, baby, has suffered from a lack of in depth documentation– indeed, even Mugridge and Cunningham’s hip “Fit for Developing Software: Framework for Integrated Tests” book barely scratched the surface of FitNesse, thus leaving some teams in the dark as to how to effectively employ it. Luckily, with the publication of Gojko Adzic’s “Test Driven .NET Development with FitNesse” any lingering questions developers may have are now answered.

Because it’s his bag, Gojko does an excellent job of taking an application from inception to production, all the while building on technique after technique for defining FIT tables and running them with FitNesse. He does a hip job of making the case for the complementary nature of unit testing (in this case NUnit) and acceptance testing with FitNesse; what’s more, even though the programming domain is .NET, this book peels away enough of the covers of FitNesse (which is, of course, written in Java) to make it useful for anyone looking to employ the tool, man.

If you find yourself curious about FitNesse or are looking for ways to leverage domain experts more effectively, then I highly recommmend picking up a copy of “Test Driven .NET Development with FitNesse“– when you finally set the book down, you’ll find yourself a much smarter person! Dig it?

Stories are a hip mechanism for clearly communicating intent– as Scott Ambler documented on his Agile Modeling site, stories are a

high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.

What’s more, Dan North builds upon stories and defines them as

the scope of the feature along with its acceptance criteria

The beauty of stories, of course, is that copasetic customers (or domain experts, business analysts, etc) can write them– if they write them according to Dan North’s template, in which a story is essentially a series of scenarios, which read as:

• given some context
• when something happens
• then something else should happen

then these scenarios (which make up a story) form a hip way to validate that what development is building actually meets a customer’s needs.

For instance, because it’s your bag, imagine a game of Blackjack, which, of course, is a simple game of cards adding up to 21. That is, each player is given two cards to start and subsequently can ask for more in an attempt to get to (or as close to) 21 without exceeding it. Essentially the player with the highest score (which isn’t greater than 21) wins the game, man.

In this case, imagine the customer is the casino (in which case, every scenario yields a bogue win for the dealer) or more specifically a blackjack dealer. The dealer could write a hip story with two simple scenarios as follows:

Story: blackjack
    scenario tie game when cards are dealt but dealer gets higher card
      given a game a blackjack game and both players have a score of 10
      when the dealer gets an ace and you get a 10
      then the dealer should win
    scenario tie game when cards are dealt but player gets higher card
      given a game a blackjack game and both players have a score of 10
      when the dealer gets a 10 and you get an Ace
      then the player should win

Using the latest and greatest hip incarnation of easyb, one can easily (did you really think I’d use a different adjective, man?) create a template that looks like this:

scenario "tie game when cards are dealt but dealer gets higher card", {
 given "a game a blackjack game and both players have a score of 10", {}
 when "the dealer gets an Ace and you get a 10", {}
 then "the dealer should win", {}
}

scenario "tie game when cards are dealt but player gets higher card", {
  given "a game a blackjack game and both players have a score of 10", {}
  when "the dealer gets a 10 and you get an Ace", {}
  then "the player should win", {}
}

As you can see, this copasetic code demonstrates two scenarios and would conceivably reside in a file named something like BlackjackStory.groovy– you’d of course need to fill in the business logic to verify the intended behavior. For example, the first scenario could be fulfilled as follows:

scenario "tie game when cards are dealt but dealer gets higher card", {

 given "a game a blackjack game and both players have a score of 10", {
  player = new Hand(Card.FIVE, Card.FIVE)
  dealer = new Hand(Card.TWO, Card.EIGHT)
  game = new Game(player, dealer)
 }

 when "the dealer gets an Ace and you get a 10", {
  dealer.hit(Card.ACE)
  player.hit(Card.TEN)
 }

 then "the dealer should win", {
  ensure(game.status()){
   isEqualToloss
  }
 }
}

You can then execute this story via Ant with easyb.

 <target name="behaviors" depends="unit-test">
  <taskdef name="easyb" classname="org.disco.easyb.ant.SpecificationRunnerTask">
   <classpath>
    <fileset dir="lib">
     <include name="**/*.jar"/>
    </fileset>
   </classpath>
  </taskdef>

 <easyb failureProperty="easyb.failed">
  <classpath>
    <path refid="build.classpath" />
    <pathelement path="target/classes" />
  </classpath>

  <report location="target/story.txt" format="txtstory" />
   <behaviors dir="behavior">
    <include name="**/*Story.groovy" />
   </behaviors>
 </easyb>

 <fail if="easyb.failed" message="easyb reported a failure"/>

</target>

The most hip part of this whole groovy thing is that after successfully invoking the behaviors target via Ant, you’ll get a story printed (in my case target/story.txt) that looks like this:

9 behavior steps executed successfully
  Story: blackjack
    scenario tie game when cards are dealt but dealer gets higher card
      given a game a blackjack game and both players have a score of 10
      when the dealer gets an Ace and you get a 10
      then the dealer should win
    scenario tie game when cards are dealt but player gets higher card
      given a game a blackjack game and both players have a score of 10
      when the dealer gets a 10 and you get an Ace
      then the player should win

In this Age of Aquarius, anyone (like customers, management, dance partners) can read that output and get a warm fuzzy feeling that their requirements are actually being coded! What’s more, if something breaks, the output will indicate a failure. Can you dig it?

Stories are hip. Stories are cool. Stories are easy with easyb, man!

Ensuring objects behave accordingly has been the primary goal of easyb; yet, initial attempts to utilize JBehave’s ensure framework seemed a bit too formal, man– the ensureThat chaining works naturally in Java (i.e. ensureThat(value, eq(false))); however, in Groovy it seems forced (i.e. ungroovy, baby).

Accordingly, easyb is in the process of introducing a new syntax for ensuring hip behavior via an ensure closure, that attempts to make object verification more natural. For example, taking the action of ensuring some value is false looks like:

ensure(value) {
 isFalse
}

or you could do:

ensure(value) {
 isEqualTo(false)
}

In fact, you can drop the ()’s too:

ensure(value) {
 isEqualTo false
}

As a side note, we want to provide a more simplified call, such as is false, however, is is defined magically in Groovy on all objects, so we’re working through this feature.

That’s a fairly simple example (how often is verification as easy as checking for false, man?).

Imagine you have a copasetic Person object (a plain old Java object, that is) that’s returned upon a find call or something and you’d like to ensure the Person object isn’t null and that a property, firstName, is some value (say “Kristen”).

Using the new easyb ensure syntax, it looks like this:

ensure(person){
 isNotNull
 and
 contains(firstName:"Kristen")
}

Note, the person object is a Java object– it looks like this:

public class Person {
 private String firstName;
 private int age;

 public Person(String firstName, int age){
  this.firstName = firstName;
  this.age = age;
 }

 public String getFirstName() {
  return firstName;
 }

 public void setFirstName(String firstName) {
  this.firstName = firstName;
 }
 //...the rest omitted
}

If you wanted to ensure the age property was another value, you can add it to the map as follows:

ensure(person){
 contains([firstName:"Kristen", age:11])
}

The ensure clause can also evaluate expressions. If it’s your bag, and you don’t require a more rich verification, you can simply write stuff like:

ensure(value == 1)

Taking the first example (the top of this entry) where some value was supposed to be false, then becomes even easier:

ensure(!value)

Of course, the expression can be anything that resolves to a boolean.

ensure("this".equals("this") && "this" instanceof String)
and
ensure(!"this".equals("that"))

easyb is all about easy BDD, baby– the framework is evolving nicely and an updated release is imminent, which will formally include the new ensure syntax along with some more emphasis on stories and scenarios. Of course, if it’s your bag, baby, you can grab the source right now (apparently anonymous check-outs aren’t working so you’ll need to create a quick account on QualityLabs.org though)!

Behavior driven development has been my bag lately; in particular, I have found the subtle shift in thinking in terms of behavior easier than that of tests. By thinking about behavior (which is, in essence, the specification of a hip object, for example), it becomes easier to validate things early-– in fact, when thinking in terms of a specification, it becomes copasetically easy to write things upfront. What’s more, one exceptional BDD framework, RSpec, has a remarkably hip DSL that reads like plain English, making the whole process easy (and fun).

Seeing how easy BDD is with RSpec inspired me to explore some similar options in Java– specifically, I teamed up with some hip friends and leveraged Groovy to create a flexible DSL for defining behaviors. The result is a framework dubbed easyb, baby.

easyb specifications are written in Groovy and are run via Java (currently, the command line or Ant); what’s more, easyb supports a few different styles of specifications ranging from RSpec’s copasetic it to a more story based DSL with disco givens, whens, and thens. The end result is a groovy framework that allows you to easily verify the behavior of normal Java objects, applications, packages, etc. Check out easyb today and see just how easy it is, man!

Many thanks to QualityLabs.org for hosting easyb– don’t forget to subscribe to the RSS feed to keep up with the project (and stay in the groove too)!