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?

While I don’t spend a lot of time on the .NET platform anymore, I’m still a big fan of Boo. Having cut my teeth on Python many years ago, I’ve always enjoyed hip Pythonic languages and when Boo came out for the .NET platform way back when, I jumped on the opportunity to experiment with it and leverage it at client sites. What’s more, it’s no secret that I’m a fan of DSLs as I do find they can be quite powerful, for example, in leveraging natural language semantics that enhance the “user experience” such as with expressing intent.

Thus, when I had a chance to read Ayende Rahien‘s “DSLs in Boo“, I jumped at the opportunity, baby! Ayende does a great job of of introducing the notion of DSLs (interestingly, there isn’t a ton of literature here specifically about DSLs alone other than Martin Fowler‘s bliki and of course, Wikipedia) in the first chapter, specifically covering the various types of DSLs (i.e. internal, external, and he goes on to define graphical ones plus he reluctantly includes fluent interfaces). What’s more, he also explores why one would want to write an DSL. Here he covers a few reasons, but a quote stuck out regarding one particular reason, which is for expressing

rules and actions in a way that’s close to the domain and understandable to business people

This is, of course, the intent of easyb — that is, to express intentions in an easily understandable language that stakeholders can grasp.

After chapter 1, Ayende goes on to cover the basics of Boo, which, of course, would be needed should you want to actually create a DSL in Boo! It isn’t until chapter 4, however, that you start to get your hands dirty coding DSLs; nevertheless, I understand the need to introduce the various required concepts leading up to chapter 4. Thus, in chapter 4, a few high level examples are covered.

Later chapters go into some details about writing and maintaining DSL code; plus, in chapter 7, he unveils Rhino DSL, which is an open source project that facilitates authoring DSLs in Boo (Ayende, by the way, is a prolific coder — he’s all over the map in the .NET world). Chapter 8 finally covers testing a DSL, which I can attest as quite difficult but paramount to a DSL’s success and stability. He also goes on to cover versioning, which I found quite intriguing as backward compatibility is a double-edged sword.

What I find most interesting is the way in which a base language affects the resulting implementation of a DSL (i.e. the end result). That is, Pythonic DSLs still have the oft complained about “white-space issue.” For instance, here is a code snippet from the book for an order processing engine:

upon auth_denied:
  when preferred_customer:
       delay_order_until_payment_is_authorized "preferred customer benefit"
  when default_customer:
       cancel_order "no money, no order"

Note how the underlying language (Boo) forces the DSL to use spaces (rather than say brackets or def/do/end like calls), what’s more, underscores (i.e. _) are required so as to keep the compiler happy. It’s, in many ways, the same in something like easyb (which is, of course, backed by Groovy), which is essentially forced to use brackets and in one case, a comma like so:

given "a preferred customer", {
  //blah blah
}

Note how Groovy requires the DSL to include a comma between the description String and the Closure. Ruby, by the way, and in the case of something like RSpec, doesn’t have this requirement. For instance, in RSpec:

it "should return item enqueued" do
  @queue.enqueue("test")
  @queue.dequeue.should == "test"
end

Yet, notice the do and end! Needless to say, you can see similar influences in something like Scala too.

DSLs are interesting beasts and they’ve clearly affected productivity on various platforms (need I remind you that Rails is a DSL?). “DSLs in Boo” specifically explores DSLs on a specific platform, yet it’s still an interesting read. Because it’s my bag, I’m definitely looking forward to more books exploring DSLs as a main subject! All in all though, this is an interesting book regardless of your chosen platform. Can you dig it, man?

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!

SDTimes recently published an article entitled “Five changes for application development in 2010” in which they reference a newly released Forrester report. This report attempts to delineate five changes regarding how development will be conducted in 2010 (and beyond) based upon the less than ideal economic climate we’re currently living in. In fact, the authors of the Forrester report use the term “lean and mean” to describe the focus going forward, which stresses lowering overall IT costs and staying focused on those projects that provide real business value.

Without surprise, the first aspect listed in the report is an embracing of cloud computing by IT organizations. The SDTimes article states that the cloud

will speed delivery of custom applications by enabling organizations to leverage infrastructure-as-a-service platforms, rather than having to buy, install, and configure servers, storage and networks.

Indeed, the premise of the cloud’s lowering of IT costs is reality, baby — rather having to buy and build an infrastructure up front (like we used to do), teams can essentially defer this cost until such time as a live environment is required; more over, that environment can be spun up on demand at a fraction of the cost of having to purchase hardware up front. What’s more, the cloud accounts for your costs associated with power and even personnel.

Next, the article refers to “finding your inner startup” where teams can

streamline processes, as well as the tools and platforms they use in development, and jettison those that no longer make sense to the business.

In many ways, this is related to the next aspect, which

focuses on lowering costs by moving from big, expensive Java and .NET platforms to less-expensive alternatives such as Adobe Flex, Apache Tomcat, Dojo, Google Web Toolkit, and other open-source platforms and frameworks.

As I see it, they are both related; that is, in many ways, streamlining development is all about writing less code and borrowing as much of it as possible. That is, leverage open source across the board. Practically the entire development infrastructure can be borrowed at this point: IDE? Covered by Eclipse. Database? Covered by MySQL. App Server/web server? Covered by a bevy of applications ranging from Apache to Tomcat to Geronimo.

In fact, there’s a great quote regarding a commercial company’s move to Geronimo:

When a large retailer recently chose to deploy Apache Geronimo to more than 4,000 of its retail stores, its resulting software license costs was pretty compelling: 4,000 times 0 equals 0.

What’s more, everything in between is available too — ORM? Done. Hibernate. Testing? Done. JUnit, easyb, Spock, etc (the list goes on and on). Logging? Do I really have to list this one?

Clearly, as far as streamlining processes goes, it’s all about some form of agility. This isn’t some trend or fad — agile processes work and work quite nicely. Call it lean, call it mean, the fact of the matter is that agile, when done right (read done with discipline) produces working features that a business wants fast.

Finally, the report lists a focus on the user experience as key along with developing internal talent (i.e. training and conferences).

In short, 2010 is bound to be the year of Development 2.0, baby. Or at least that’s what Forrester Research thinks!

In March, I’ll have the distinct pleasure of joining a number of hip friends in speaking at the Enterprise Software Development Conference (or ESDC) in San Mateo, California. I’ll be giving four different one hour presentations ranging from leveraging Groovy in the real world to RESTful concepts with Grails to Behavior Driven Development with easyb, and finally, cloud computing with both Amazon’s EC2 and Google’s App Engine.

In many ways, these talks coincide with my thoughts regarding effective software development that is both rapid and lean (i.e. provides real business value without breaking the bank). What’s more, from perusing the course catalog there’s a cornucopia of similarly related themes such as Agile software development and Web 2.0 technologies. If you are planning on attending, please stop by and say hi!

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!

One more than one occasion, I’ve found myself yearning for a more functional paradigm that facilitates easier concurrency programming on the JVM. And while Erlang is an excellent platform for concurrency, it doesn’t run natively on the JVM; thus, the next logical choice is none other than Scala (yes, Clojure is a choice as well and I’m currently reading Stu’s tome, “Programming Clojure“!).

Scala’s syntax is anything but similar to Java; what’s more, its constructs and its implementation of the actor model are all but alien to those programmers raised on a diet of Java; nevertheless, my friend Venkat does a superb job of clarifying the language with a cornucopia of examples and well articulated pages that, at least for me, revealed Scala in a concise and easy to grasp manner. And while there’s no shortage of freely available tutorials on Scala, I found Venkat’s writing as well as his examples much more approachable and practical to everyday issues (as opposed to more academia-like approaches).

Indeed, due to Venkat’s easy to read style, I’m already employing Scala on mission critical applications that rely on Scala’s implicit concurrency accommodations. In truth, I found the first half of his book indispensable in ascertaining how to actually program in Scala as its syntax is distinct from Java (although, I found myself more and more thinking that the authors have a fluency in Python — the concepts and syntax on many occasions are quite similar).

The book provides an excellent journey — it starts out easy — that is, the pace is helpful for the beginner as Venkat explores basic features, classes, typing, etc and then proceeds to some super interesting subjects like functional programming, Scala’s traits, collections, Java interoperability, followed by concurrency. Plus, he throws in the mix a chapter on using ScalaTest. Lastly, he puts everything together quite nicely with a nice example application for ascertaining stock prices (by which he demonstrates Scala’s impressive XML handling).

All in all, I enjoyed reading this book (as evidenced by the myriad highlighted sentences and example code) and indeed, working through the book gave me the extra confidence to embrace Scala quickly in a production environment.

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?