For the last year or so, I’ve been using Atlassian’s Bamboo (in the OnDemand variant) for our team’s build server. And, mostly, it’s an awesome tool. Some parts, however, are a little rough around the edges. Building dependent projects is one of them.
Having succeeded in getting a simple JBehave story running. my next challenge is to scale it up a bit. In particular, I want to get a JBehave story that integrates with Spring to do something more fully-featured: save an entry in a database.
In any battle between the source code and the documentation, the documentation always loses. Note that this is not the same thing as the source code winning.
In the last segment, I managed to get JBehave reporting under Maven using a pre-canned example. This time, I want to tackle the other extreme – I want to develop a single story in JBehave and see what’s the bare minimum it takes to get it running, inside an IDE (in my case, Eclipse)/
JBehave comes with some very comprehensive examples, so I thought I’d start there to see if I could get one of them building – and reporting – under Maven. The example I chose was the ‘trader‘ example, which you can see at github.
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.
There are three basic approaches to writing software that I know of. The first is always strive for technical excellence. This is great if you can do it – I’ve never worked in a place where technical excellence was always priority #1 with no compromise. If that’s you, then you probably don’t need to read this.
The second way is throw code around and hope it works – this is far too common. You look at the problem in front of you, and you grab a solution that’s good enough for now, doesn’t blow the budget (time and money) too badly, and leave the mess to be cleaned up (or worked around) later. Industry wide, this is the norm – a consequence of always focusing on the short term.
The third is a pragmatic compromise – try to make it as good as possible, while recognising that parts of the system will be, well, shit. That’s what I want to talk about here.