Adventures in Learning… JBehave

A couple of years ago, I got the ‘specification-by-example’ bug. I was playing with this new project called Cucumber, and was really enjoying the idea of specifying examples in an English-like syntax that testers and BAs could supposedly read. (I say supposedly, because it never really took on at my previous place-of-employment. Which was a shame). Nonetheless, I enjoyed it, and advocated it when and where I could. Heck, if nothing else, it was an excuse to write support code in Ruby as a break from the Java stuff.

Now, at least, I’m back in pure-Java land. But I want to use these example-based tests still – in fact, the project I’m working on at the moment (essentially an ETL tool) could really benefit from it. So I’m looking around for a ‘specification-by-example’ tool for Java.

The obvious one – and the one I’m looking at now – is JBehave. It’s the spiritual ancestor of Cucumber, after all, and it supports the same Gherkin-style external tests. Unfortunately, while I was able to get a test running inside my IDE fairly fast, I hit all sorts of issues trying to do it as part of my build process, and as a contractor being paid by the hour, it’s not really fair on the client to spend too much time yak shaving, so I had to back it out and replace it with a less-readable, but functional, JUnit version.

That said – I still kind of want to shave that yak. So I’ve created a github repo where I’ll be doing some spikes to explore how JBehave actually works. I’m doing this in public because the actual doco on JBehave is, um, poor quality? For example, look at the basic doco for developing stories, and the “one-to-one” JUnitStory – I mean, that code does work, but using it is just a pathway to cargo-cult programming. I like to understand the tools I work with, thank you very much.

So the next few posts I’m likely to do will be a series of notes on my spikes and what I find out. If you find it worthwhile, let me know. If you don’t… well, nobody forces anyone to read this.

Here are the goals I have for this exercise:

• I want to be able to write some simple stories. I’m not too concerned about making the stories complicated or using advanced features for now.
• I want to use these stories as part of my unit-testing flow – so similar rules to normal unit tests apply.
• I want to run these stories as part of my Maven build. Why Maven? Well, Maven is the New York of Java build tools – if you can make it there, you can make it anywhere. I’m not fond of Maven, by any means (feel free to look at previous posts I’ve made on the subject), but I am realistic. If I want to use JBehave with a client, I need to know how to make it work under Maven. Making it work with other build tools (like Gradle) can happen later.
• Because it’s Maven, I want to apply Maven’s rules on the filesystem layout – which, by and large, I agree with. This means, for example, that all JBehave code should be somewhere under src/test – not src/main (which is where the JBehave examples all put it). Similarly, I want the stories to run as part of the ‘test’ phase in Maven – preferably after unit tests, but I’m not that fussed.
• I do want decent reports out the build – at least as good as the textual or HTML reports that Cucumber put out.
• While I’m not going to be using JBehave for integration testing (yet), I am going to want to use it to test decent chunks of an application at a time. I’m thinking of having it hit a service layer and persist to an in-memory database – achieving a near end-to-end test. What that means, in practice, is that I want to have my JBehave steps integrate with Spring-wired components, including things like @Transactional aspects. (Why Spring? Same reason as Maven – it’s the default choice in Java land, at least if you’ve managed to escape EJB hell)
• I also want to be able to run my tests inside my IDE of choice (Eclipse, in this case), and get somewhat sensible output. The gold-standard would be how RubyMine/IntelliJ runs Cucumber tests, but I’ll settle for each scenario being shown as a test for now.

History tells me that I’m going to take my time doing this – I’ve got lots of “half-done” projects. 😉 So I’ll be doing it in chunks, and as I figure things out, I’ll post updates.

Author: Robert Watkins

My name is Robert Watkins. I am a software developer and have been for over 20 years now. I currently work for people, but my opinions here are in no way endorsed by them (which is cool; their opinions aren’t endorsed by me either). My main professional interests are in Java development, using Agile methods, with a historical focus on building web based applications. I’m also a Mac-fan and love my iPhone, which I’m currently learning how to code for. I live and work in Brisbane, Australia, but I grew up in the Northern Territory, and still find Brisbane too cold (after 22 years here). I’m married, with two children and one cat. My politics are socialist in tendency, my religious affiliation is atheist (aka “none of the above”), my attitude is condescending and my moral standing is lying down. View all posts by Robert Watkins