The Disco Blog

The easyb team has recently released version 0.9.7, which contains a scattering of features and fixes including one of my favorites: behavior tagging. Briefly, behavior tagging permits the isolation of behavior groups. Much like TestNG’s group annotation, tags in easyb allow you to selectively execute a group of behaviors — this is a handy feature on a number of fronts, not the least of which is test categorization.

What’s more, version 0.9.7 now supports the ability to generate a report of all behaviors without having to run the suite itself; that is, you can generate a listing of all behaviors, which will be marked as “in review” — this is distinctly different than a “pending” state as “in review” behaviors could be either implemented or not; what’s more, they could even be failing. The intent of “in review” is for reviewing the natural language behaviors (i.e. goals) with team members, stakeholder, etc.

Version 0.9.7 also leverages Groovy 1.7.2; plus, there are a few DSL changes, such as but is now supported (works just like and) along with shared_behavior can now be written without the underscore (i.e. shared behavior — this is much like narrative‘s as a and i want).

For more information about what’s in 0.9.7 check out the release page. You can find the 0.9.7 download on easyb’s project page. Thanks to everyone in the community for your support!

I recently had the opportunity to present four different talks at the Enterprise Software Development Conference (or ESDC) in San Mateo, California. In an effort to provide additional data points and information, I created individual resource pages for each talk. These pages (hosted at my company’s site — beacon50.com) provide links to articles, blog entries, tutorials, and a copy of each presentation. If you’re curious to see what you missed at ESDC, then have a look, man:

• Resources for Groovy from the trenches
• Resources for Easy BDD with easyb
• Resources for Comparing the cloud: GAE versus EC2
• Resources for RESTful web services in Grails

Thanks to everyone who came to ESDC and attended my talks — I had a great time discussing these topics (and more!) with you!

Back in the Age of Aquarius, I wrote an article entitled “Use test categorization for agile builds” in which I attempted to delineate various types of tests and then went on to suggest how to categorize these various tests so as to get the most out of a build run (i.e make it fast and effective at providing meaningful feedback). Back then (and to an extent now) my concern was with test execution; that is, I like to categorize tests as fast and slow. Accordingly, I run the fast ones all the time, such as before I check-in (I prefer a fast build to be less than 3 minutes — longer and I get bored). What’s more, for the slow ones, I usually schedule a build (via Hudson, for instance) that runs them hourly, nightly, etc — it all depends on how slow they are, man!

As it turns out, unit-like tests are usually the fast ones and functional-like tests are the slow ones. This all makes sense as functional ones usually require a lot of test up, like seeding a database or firing up Selenium.

Categorizing tests by execution speed it helpful, but a bit broad in some cases. Thus, I often find myself grouping tests (or behaviors) by feature, behavior or goal. That is, there might be a macro-feature in development broken up by a series of stories (or tests) and I find it’s helpful to run those stories as a group in isolation for focus. Those behavior groups are then aggregated into iteration builds that correspondingly execute all targeted behaviors, for instance.

This exercise, combined with the influence of TestNG (which supported test groups long long ago) has lead to a new feature in easyb: tags. With the tags keyword, you can categorize a behavior and then exercise only those desired behaviors via the -tags command line option or via the tags attribute in easyb’s Ant task, for instance.

Thus, the following story is tagged as “23949314″ — this happens to be a Pivotal Tracker story ID and in the current iteration, there are 4 stories 23949314, 23949315, 23949316, 23949317.

tags "23949314"

scenario "AcmeFoo should support expired account deletions"
scenario "AcmeFoo should support child account deletions"

The beauty here is that when this particular story is run, its status is pending, thus providing some status as to a particular feature.

Going forward in this iteration, subsequent easyb stories are tagged with appropriate IDs (23949315, etc) and during this iteration, builds are run that exercise these particular tags in isolation. Of course, there are other builds that exercise all other existing stories (via a build pipeline) so as to perform a continuous regression.

The tags keyword is flexible too — you can add multiple tags by including the tag names in a List like so:

tags ["23949314", "functional"]

scenario "AcmeFoo should support expired account deletions"
scenario "AcmeFoo should support child account deletions"

In this case, this story is tagged as both 23949314 and functional — accordingly, a build can be configured to execute only functional behaviors and, of course, this one will be included. Conversely, if a build is run with a tag such as prototype, then this particular story won’t be executed.

This is an evolving feature in easyb. Right now, only story level tags are supported. Scenario tagging is planned. What’s more, tags are currently supported in the tip of easyb’s SVN repository — if you’re eager to start using them now, you’ll have to build your own version of easyb. Otherwise, a release is forthcoming, which will contain this feature. Can you dig it?

The easyb team is pleased to announce the posting of a hip introductory video that demonstrates both specifications and stories in action. In this 8 and 1/2 minute video, you’ll learn that easyb enables you to express human readable expectations that verify any Java application (or to be more precise, anything running on the JVM) and that you express those expectations in Groovy.

If you think easyb concisely expresses expectations (i.e. features or requirements) in a simple, yet readable manner, then what are you waiting for, man? Download it today and see for yourself how easy behavior driven development in Java can get with easyb!

Since the 0.9.6 release of easyb, new members have joined the development team, a number of new features have been added, more than a few issues have been addressed, and the easyb community of projects continues to evolve! For those of you living on the bleeding edge, you can build 0.9.7 from the trunk; conversely, an official 0.9.7 release is forthcoming.

In the meantime, here’s some of the hip news coming from the front lines of easyb development:

• easyb now has an Eclipse plugin!
• There’s a new XMLUnit plugin, which facilitates using XMLUnit along with easyb
• There are new wiki pages documenting, for example, how to create easyb plugins, how to use the XMLUnit plugin, and how to leverage Mockito
• As a new feature, underscores are no longer needed when defining shared behaviors (i.e. the keywords are now shared behavior although the keyword shared_behavior still is valid
• You can now obtain a print out of story text without executing them
  • unexecuted stories will be marked as “in-review”
• The keyword “but” is now supported
  • it technically works just like “and” and was added to support further readability of scenarios
• There’s a new maven plugin release
  • simply update your POM and you’ll be good to go
• There has also been a new release of the easyb IntelliJ plugin
  • easyb now works with IntelliJ 9.0
  • you can find the new version in IntelliJ’s Plugin Manager
• There is a new project dubbed easyb-junit, which “provides a way to run easyb behaviors through JUnit”
• The popular Griffon project has an easyb plugin (this plugin has been available for quite some time)
• There have been improvements made to the easyb Grails plugin as well as documentation enhancements
• Using easyb with Gradle has been documented
• A number of issues have been closed including 145, 165, 168, 169, 133
• easyb now builds against Groovy 1.7.0

Indeed baby, these are fun times for easyb! Many thanks to the community for its continuing enthusiasm and help — the easyb team can’t do it without you.

If you want to get involved, join the mailing list, suggest features (or document defects), follow the project on Twitter, and spread the good news!

From time to time, I’ve found that mocking various dependencies can be helpful in testing behavior. Briefly, mocking an object allows you to fake its behavior so as to more fully isolate some other object depending on this behavior — the classic use case is that of mocking a data access layer, for example. In this case, testing some object that depends on a DAO object becomes a bit easier if you can mock out the DAO and thus not have to worry about an associated database, etc.

There are a plethora of mocking libraries out there (and in many cases, you can roll your own!) — one of my favorites for a long time has been EasyMock. This library has served its purpose for me when I’ve needed it; however, there’s a newer library on the block dubbed Mockito, whose hip description is best read word for word:

Mockito is a mocking framework that tastes really good. It lets you write beautiful tests with clean & simple API. Mockito doesn’t give you hangover because the tests are very readable and they produce clean verification errors.

Indeed, Mockito can mock classes just as easily as interfaces and in many ways, I’ve found its API to be much more natural and BDD-istic. Watch.

Each library is similar in spirit — for instance, when providing a stubbed implementation of a hip object, you request a mock of it and then you instruct the various frameworks on how to behave. For instance, with EasyMock, if you’d like to mock an instance of a Feed class (don’t worry too much about this class, suffice it to say, it is used in a ScoreBoard class, which is the class under test), you can do it like so:

scenario "using easy mock", {
  given "a mocked instance of feed", {
    feed = createMock(Feed.class)
    expect(feed.allScores()).andReturn( [new FootballGame(
        "Cleveland Browns", 20, "San Diego Chargers", 3)] as FootballGame[]
    )

    replay(feed);

  }
  then "things should work normally", {
    scoreBoard = new ScoreBoard(feed,
            new FootballGame("Washington Redskins", 0, "New York Giants", 45));

    games = scoreBoard.getAllScores()

    games[0].awayTeamScore().shouldBe 3
  }
}

As you can see in the EasyMock example (which is being driven via easyb), the Feed class’s allScores method is stubbed — in this case, a fake score is created (rather than say, retrieved from a live scoring system located on another server, for instance). Note how with EasyMock, the fluent interface-like API reads expect and return. With EasyMock, things get started via the replay method — as you can see, later in the scenario, this behavior is validated, thus demonstrating the mock.

EasyMock is definitely easy; however, watch the same example play out with Mockito:

scenario "using mockito", {
  given "a mocked instance of feed", {
    feed2 = mock(Feed.class)
    when(feed2.allScores()).thenReturn([new FootballGame(
       "Cleveland Browns", 20, "San Diego Chargers", 3)] as FootballGame[]
    )
  }
  then "things should work normally", {
    scoreBoard = new ScoreBoard(feed2,
            new FootballGame("Washington Redskins", 0, "New York Giants", 45));

    games = scoreBoard.getAllScores()

    games[0].awayTeamScore().shouldBe 3
  }
}

On the surface, things look to be the same, however, if it’s your bag and you look closely, you’ll see that Mockito’s API reads nicer: when then return — this is quite BDD-like, no? Plus, Mockito doesn’t require a replay-like call. Thus, to me, Mockito is a bit cleaner — it certainly complements easyb stories and scenarios with its when and thenReturn API calls.

While I’m only scratching the surface of features available in both libraries, Mockito’s API is more in tuned with my way of thinking — can you dig it, man?

Because it’s my bag, I’ve recently taken to learning Scala. In particular, I’ve run across some situations where I’ve known instinctively that a more functional language (i.e. one that avoids state and mutability) would have perhaps made the task at hand a bit easier or at least safer to code (think situations involving threads (i.e. concurrency), for instance). And while I’ve thus far handled those situations with various libraries and frameworks on the JVM (either straight Java or via Groovy), Scala has always held my interest in that the language is functional by nature — that is, functional aspects are intrinsically present as opposed to added in or forced via additional libraries, etc.

One of my favorite techniques for learning a new language is to leverage it via a testing framework — that way, you get to learn the syntax while also learning about how the language behaves. For instance, because BDD is my bag, I thought I’d start things off by writing a few behaviors with ScalaTest. Briefly, ScalaTest is

an open source test framework [written in Scala] for the Java platform designed to increase your productivity by letting you write fewer lines of test code that more clearly reveal your intent.

Interestingly, they team behind ScalaTest has even trademarked the slogan

Less code, more clarity

Of course, I’m all about less code and more clarity — I’m all about easy, baby! So I thought it would be fun while learning about Scala to also compare and contrast Scala and ScalaTest to Groovy and easyb. Before I go any further, please allow me to state, for the record, that I’m much for familiar with Groovy than Scala and that I’m almost certainly biased towards easyb no matter how hard I might try to admit otherwise. Nevertheless, I do believe I can be objective in this situation as I am intent on leveraging Scala where appropriate.

The ScalaTest team has done a wonderful job of documenting the various options available for testing; in fact, they’ve got an entire section dedicated to BDD-style testing; in particular, they have an RSpec inspired syntax that is obviously similar to easyb’s specification syntax (which was also inspired by RSpec). Thus, with ScalaTest’s Spec trait, you can leverage an it-style syntax for behavior verification; plus, via Scala’s mix-ins feature, you can also leverage a more natural should-style of verification, which definitely leads to a more readable specification.

Using the ScalaTest documentation, you can create a specification that describes a stack like so:

import org.scalatest.Spec

class ExampleSpec extends Spec {
 describe("A Stack") {
  it("should pop values in last-in-first-out order") (pending)
  it("should throw NoSuchElementException if an empty stack is popped") (pending)
 }
}

This is, of course, runnable and yields a report that states that there are two pending tests (or behaviors). Note, with ScalaTest, you must indicate a specification is pending by appending a (pending) clause.

Conversely, with easyb, the same specification can be written like so:

description "this specification describes a stack"

it "should pop values in last-in-first-out order"
it "should throw NoSuchElementException if an empty stack is popped"

What’s noticeably lacking from easyb’s syntax is the describe clause (which, in many ways, is just like a scenario); however, easyb doesn’t force you do declare that a particular behavior is pending — it’ll figure that out by itself. What’s more, you aren’t forced to create a class structure to contain your specification. You don’t have to import anything either.

Next, when you decide to code your behavior, in ScalaTest, you implement the it‘s method body like so:

import org.scalatest.Spec
import org.scalatest.matchers.ShouldMatchers
import scala.collection.mutable.Stack

class ExampleSpec extends Spec with ShouldMatchers {

 describe("A Stack") {
  it("should pop values in last-in-first-out order") {
   val stack = new Stack[Int]
   stack.push(1)
   stack.push(2)
   stack.pop() should be === 2
   stack.pop() should be === 1
  }
  it("should throw NoSuchElementException if an empty stack is popped") {
   val emptyStack = new Stack[String]
   evaluating { emptyStack.pop() } should produce [NoSuchElementException]
  }
 }
}

As you can see from the code above, this behavior is validating a simple Stack object– in this case, its Scala’s own stack implementation; suffice to say, it behaves, for the most part, just like a normal stack. First and foremost, ScalaTest’s ShouldMatchers mixin is slick! Note how you can literally write should be and then pass in a condition. I think this syntax reads nicely (except for the fact that ScalaTest is using 3 =‘s). Moreover, exception verification is quite nice too — the evaluating line is quite elegant and the keyword produce is hip! I take it the produce clause takes a collection of exceptions, so it would be nice if, in the case of only one exception, you could drop the [] syntax though.

ScalaTest also has another mixin type dubbed MustMatchers, which replaces should with must should you want to use that word instead.

The same verification process in easyb looks like so (note, in the code below, I’m going to use Java’s Stack):

description "this specification describes a stack"

it "should pop values in last-in-first-out order", {
	stack = new Stack<Integer>()
	stack.push 1
    stack.push 2
    stack.pop().shouldBe 2
    stack.pop().shouldBe 1
}
it "should throw EmptyStackException if an empty stack is popped", {
	emptyStack = new Stack<String>()
	ensureThrows(EmptyStackException){
		emptyStack.pop()
	}
}

In easyb’s case, the actual assertion-like clause is shouldBe (or its cousins like shouldEqual, etc); what’s more, you must “attach” the clause to the desired object (as opposed to ScalaTest’s more removed syntax, which allows you to drop .’s). Nevertheless, the shouldBe call doesn’t insert an additional operator either (i.e. there isn’t the ===). easyb’s exception verification is certainly not as nice as ScalaTest’s though — I suppose I could write the ensureThrows clause as one line but it doesn’t read as nicely as evaluating { blah } should produce [Exception] — I really like that syntax in ScalaTest.

As you can see from these two simple examples, the spirit of BDD is there — each framework takes a slightly different approach in terms of syntax, but that’s probably due to the underlying nature of the languages themselves. Scala is certainly less verbose than normal Java, but it seems to me that Groovy is less verbose than Scala (but I concede that this might just be a result of each framework’s syntax) . I find that easyb yields more clarity but I do find that ScalaTest’s matchers syntax to read quite nicely.

Scala is definitely an interesting language that exposes some interesting features. Like every other major player on the JVM, it has its spot — for me, the strict nature of its typing and functional-ness makes it applicable in concurrency situations; however, its syntax, while less verbose than that of Java, isn’t necessarily as flexible as Groovy, for instance (although dropping the dot (“.”) on method calls makes successive method calls read copasetically (i.e. should be)).

ScalaTest is well documented and offers quite a few neat options (via Scala traits & mixins) that make testing a lot more interesting and certainly clearer than plain Jane JUnits; however, for me, I still find easyb’s syntax to be much more clarifying (and of course, much less code). Nevertheless, for Scala code that I do write, I’ll be leveraging ScalaTest — it’s already taught me a few things! Can you dig it, man?

There’s myriad ways to validate XML these days; in fact, with Groovy, the mechanics of parsing XML with XMLSlurper couldn’t be easier! Nevertheless, from time to time, because it’s my bag, baby, I’ve found that I’ve needed an easy way to validate XML documents without having to actually parse them myself. Thus, XMLUnit has been a handy framework today as it has been for years.

While XMLUnit is a hip JUnit-style framework, you can certainly leverage it outside of JUnit. What’s more, via easyb’s plug-in framework, using XMLUnit just got a lot easier! For instance, leveraging XMLUnit without the new plug-in required a bit of manual manipulation of XMLUnit’s Diff class and then a boolean verification like so:

import org.custommonkey.xmlunit.XMLUnit
import org.custommonkey.xmlunit.Diff

XMLUnit.setIgnoreWhitespace(true)

scenario "the XMLRepresentationBuilder should build XML", {

 given "a table name and collection of name value pairs", {
   lst = [new ColumnNameValue("LN_ID", 10002130),
     new ColumnNameValue("NIBA&quot", "99.99"),
     new ColumnNameValue("EFF_DATE", "2009-04-01")]
   map = ["LN_ID":"id", "NIBBA":"nb","EFF_DATE":"effectiveDate"]
 }

 then "the XML produced should be valid", {
   rep = new DatabaseTableResource()
   rep.columnNameValues = lst
   rep.columnNameMappings = map
   rep.identifiers = ["LN_ID"]
   out = XMLRepresentationBuilder.buildRepresentation(rep)

   control = """<cmnres id='10002130'>
      <nib>99.99</nib><effectiveDate>2009-04-01</effectiveDate>
      </cmnres>"""					 

   diff = new Diff(control, out)
   diff.identical().shouldBe true
 }
}

Note how in this code it’s necessary to:

• Ensure white space doesn’t cause comparison errors via the XMLUnit.setIgnoreWhitespace(true) call
• Use XMLUnit’s Diff class to compare two documents and then call the identical (or similar) method to actually verify the documents

With easyb’s XMLUnit plug-in, things are a lot simpler! All you need to do is insert a using clause and ensure the plug-in is in your classpath. Watch:

 using "xmlunit"

scenario "XML documents are compared easier via xml unit plug-in", {  

  given "some xml document", {
    control = """<account><id>3A-00</id><name>acme</name></account>"""
  }

  then "the plugin should enable easy comparisons", {
    testXML = """<account><id>3A-00</id><name>acme</name></account>"""
    testXML.shouldBeIdenticalTo control
    testXML.shouldBeIdenticalWith control  //same behavior different call
    testXML.shouldBeIdentical control      //ditto
    testXML.identical control              //ditto
  }

  and "the instance of XMLUnit should be available for use", {
    XMLUnit.version.shouldBe "1.3alpha"
    XMLUnit.getIgnoreWhitespace().shouldBe true
  }
}

Notice that there isn’t any need to alter the white space setting (it’s been done for you in the plug-in — yo can undo it easily too — see the and clause?), nor is it necessary to use XMLUnit’s Diff class — it’s all done under the covers. While this story uses the identical call, there is a corresponding similar call (and related pattern — that is, shouldBeSimilarTo and the like).

Also, the initialized instance of XMLUnit is available should you need further configurations, etc — the plug-in inserts the copacetic instance into the binding available to your behaviors as shown in the and phrase above.

As you can see, the XMLUnit plug-in for easyb makes workin with xml (that is, comparing documents) a lot easier. While there’s plenty of ways to skin a cat, so to speak, this is just one of them — I’ve certainly found it handy from time to time — I think you will too!

You can download the current version of the plug-in at easyb’s Google code site along with a few other hip gems like easyb’s DbUnit plug-in.

The easyb team is excited to report that a hip Eclipse plug-in is in the works and an initial version is already available due to the copacetic work of both Darran White and Robert Hjertmann! The plug-in works with Eclipse 3.4 and 3.5 and currently supports running behaviors (both stories and scenarios) via the a run configuration. That is, when you right click on a story, for example, and then select the Run As option, you’ll have the choice to run the story via an easyb run configuration, which then pipes the output to the Eclipse console. Plus, the plug-in supports an Outline view, which essentially displays your behaviors without code — what’s more, you can click on an item in the outline and you’ll be taken to that spot in the actual behavior in your editor.

This is an evolving project, so please take a few moments to provide feedback either via the easyb mailing list or even by creating feature requests or defect reports via the easyb issue tracking system.

Installing the plug-in is simple too as the update site literally points to the latest version of the plug-in’s assets in our repository; consequently, the update and install URL is http://easyb.googlecode.com/svn/trunk/eclipse-plugins/org.easyb.eclipse.updatesite/ — of course as the plug-in evolves and official versions are released, the versioned plug-ins’ URLs will change (as the current URL points to the trunk of SVN).

So what are you Eclipse users waiting for? Install the easyb Eclipse plug-in and experience the fun of executable, yet readable, documentation, man.

The easyb team is excited to announce that version 0.9.6 is out! This version adds a number of hip features including:

• Re-running failed behaviors
• this is one of my favorite features of TestNG — easyb will create a file listing failed behaviors via the -outfail option, which can be passed via the command line or via Ant
• Just pass in the -f flag via the command line or Ant (see next bullet) to run those failures only
• Running behaviors listed in a file
  • Pass in the -f flag as mentioned above via the command line or Ant along with a path pointing to a file and only those behaviors listed will be run
• Running behaviors in parallel (via the -parallel option)
• A new ensure sytle method dubbed ensureUntil, which supports the notion of a timeout
• For example, the behavior below from easyb’s source leverages this new feature and demonstrates that the ensureUntil call will run the code inside the passed in closure for 4 seconds (you can see that the executed closure’s (delayedClosure defined early) value changes after 2):

  scenario "Another passing verification", {
    then "Condition passes", {
      var = 20
      delayedClosure = {i ->
        Thread.sleep(2000)
        return (i += i)
      }
  
      var = delayedClosure(20)
      ensureUntil(4) {
        var.shouldBe 40
      }
    }
  }

• Ant task updates to support new command line features mentioned above (such as -f and -outfile, man)
• Shared behaviors
• you can create a base behavior (at this point it must live within the context of a single story (i.e. a file)) and then refer to that behavior inline using the keywords shared_behavior and it_behaves_as like so:

  shared_behavior "shared behaviors", {
    given "a string", {
      var = ""
    }
  
    when "the string is hello world", {
      var = "hello world"
    }
  }
  
  scenario "first scenario", {
    it_behaves_as "shared behaviors"
  
    then "the string should start with hello", {
      var.shouldStartWith "hello"
    }
  }
  
  scenario "second scenario", {
    it_behaves_as "shared behaviors"
  
    then "the string should end with world", {
      var.shouldEndWith "world"
    }
  }

• This version leverages Groovy 1.6.4 too

Once again, thanks to the easyb community for numerous suggestions, comments, and patches! So what are you waiting for? Download easyb 0.9.6 now and have a blast verifying your Java applications, baby!