It’s November, and it seems I haven’t posted anything here since January. Partly that’s because I have a Proper Job™ these days, which means I spend a lot less time writing and blogging. Partly I’ve rediscovered the joy of actually programming, which means I get to spend most of my time hacking on code.
This is something of a catch-up post, bringing you up-to-date with some of the things I”ve been up to and some of the topics I intend to be blogging and writing about.
Read More
The brittleness of tests or specs is a recurring topic in BDD (or acceptance test-driven development, specification-by-example, or whatever you choose to call the thing where you write acceptance criteria, automate them and then make the application match). This is a tricky area, and there are probably as many styles of defining and grouping acceptance criteria as there are teams automating them.
The aspect I want to focus on in this article is domain language, because there’s a failure mode I encounter surprisingly often, which seems to have a common root cause.
I currently have a backlog of about 15 blog articles I am failing to finish. The most embarrassingly laggy one dates from around the end of 2007. Now I know I’m a slacker.
However, others have been far more industrious than me.
The industrious Yukei Wachi has followed up his translation of my Introducing BDD article by producing a Japanese version of What’s in a Story.
Inspired by Yukei’s translation, a Korean developer HongJoo Lee has written a Korean translation of Introducing BDD. How cool is that?
Enormous thanks to you both for your hard work.
Update: HongJoo has also translated What’s in a Story? into Korean.
I am delighted to announce the official Japanese translation of Introducing BDD.
It’s easy to forget how big the Internet is and how small the world can be. Last year I gave a BDD talk at QCon in San Francisco that made its way onto InfoQ.
A Japanese programmer called Yukei Wachi watched it and decided he wanted to know more about BDD. He read my Introducing BDD article and felt it was worth translating into Japanese. He then translated several thousand words in what seemed like no time at all.
Yukei asked me for a couple of sentences to introduce the Japanese translation, and then with typical Japanese modesty decided to drop the part where I thank him. So here is the introduction again with the first sentence intact.
I am thankful to Yukei Wachi for translating this article from English for you, and I am grateful to you for your interest in Behaviour-Driven Development. I hope you find this article useful, and that you enjoy your journey into BDD as much as I have.
Thanks Yukei.
I’m delighted to be taking part in a In the brain of… session organised by the folks at SkillsMatter.
When the SkillsMatter folks actually checked inside my brain and heard the rattling noise, they realised I would need some help, so Liz Keogh – BDD pioneer and project lead for JBehave – will be co-presenting with me. (If you hold Liz up to your ear you can hear The Cure.)
SkillsMatter is a fantastic training organisation that believes in creating and nurturing communities. This event kicks off a London BDD community, which is very exciting for me because it means there is a genuine momentum behind BDD as a movement. This is the first of a series of (mostly free) talks around BDD and automated testing taking place throughout the rest of the year.
The event is free to attend and it takes place at SkillsMatter’s London office on Monday 17 August from 6:30 pm. I expect we’ll go for beer afterwards.
Please register online so we know how many chairs to put out, and I look forward to seeing you there.
It’s finally happening – I’m writing a book! Well ok, the remarkable David Chelimsky is writing a book. It’s called Behaviour Driven Development with RSpec, Cucumber and Friends and myself and a few other folks are contributing in varying degrees. The book is already in beta, which means you can buy the PDF now from the Pragmatic Press and you’ll get the print version as soon as it’s ready – and still get change out of $50, which can’t be bad.
The folks at the Pragmatic Press have been brilliant – especially the ever-patient Jackie Carter – and my second chapter will hopefully be in the next beta (or if not, definitely the one after that). It’s also surprisingly satisfying to be writing in vim rather than Microsoft Word!
Well, that’s enough for now. With any luck I’ll be back blogging a bit more frequently. Next up, learning about learning, thinking about thinking and why we are so crap at estimating.
A friend of mine has a Far Side desk calendar that he describes it as a barometer for how busy he is. Some days he finds himself tearing off a whole bunch of pages because he’s been too busy or distracted to tear one off each day.
I noticed a couple of weeks ago that I haven’t blogged anything for over six months. It’s been hectic. I’m planning to be blogging more over the coming weeks and months. I’ve got a ton of things to write up, ranging from planning and estimation – it’s no wonder we are useless at it – we don’t even know where to start!, to architecture – why you wouldn’t want to go on a date with Maven, by way of build and release engineering – why Ivy means Ant is still the king of cool.
I’m in Sydney at the moment where I’ll be speaking at JAOO Australia which is in a couple of weeks time. It’s like a pocket-sized, portable version of the European JAOO conference. In fact it is two conferences, one in Sydney (May 5-8) and one in Brisbane (May 11-14). There are two days of tutorials and two days of conference proper, and it looks like it’s going to be great fun. Both conferences are small enough (a few hundred people) that there will be ample opportunity to hang out with speakers and ask the questions you really want answered. And buy them beer.
I’ll be Pimping my Architecture and doing tutorials on BDD (principles and methodology) and TDD in Java (technical workshop), the latter with the lovely Erik Doernenburg.
If you can get to either city on those dates I would highly recommend it. As of writing neither event has sold out so there is still time. JAOO is one of the best geek conferences I know, with a great mix of technology (languages and frameworks), methodology (with an Agile flavour), architecture (from cloud to iphone) and soft stuff (Your brain is deceiving you. Yes you. Even though you know it is!)
Back in 2003 I started work on a framework called JBehave. It was an experiment to see what JUnit might have looked like if it had been designed from the ground up for TDD rather than as a unit testing framework. I was also starting to use the phrase “behaviour-driven development” to describe what I meant. The jbehave.org domain was registered and the first lines of code written on Christmas Eve 2003, much to my wife’s bemusement. Over time JBehave grew a much more interesting aspect in the form of a framework for defining and running scenarios, or automated acceptance tests.
Since JBehave wasn’t based on JUnit there was always going to be a barrier to adoption in the form of IDE integration and build tools, among other things. It also failed the First Law of Frameworks in that it wasn’t harvested from real life – it was just an extended thought experiment. As a result it turns out it was a bit of a cow to use. Mea culpa.
Many of the ideas from JBehave have since appeared in other BDD frameworks, particularly in the lovely rspec. Although I wrote the first cut of the scenario runner in rspec it has since been thoroughly reworked and improved beyond all recognition1 by the efforts of David Chelimsky and his team. The biggest single improvement has been the introduction of plain text stories, which allow you to separate the scenario text from any of the automated steps they refer to.
Over the last few months, Liz Keogh and Mauro Talevi have completely rewritten JBehave from the ground up, taking advantage of new Java 5 language features and using JUnit 4 as the underlying execution framework.
By using real project examples to drive the design – including using it in their day jobs – they have produced what I believe is a powerful and very usable behaviour-driven development framework for Java. In particular Liz decided she wanted plain text scenarios and the idea of a “pending” scenario – something that you have identified but not yet implemented.
We’ve released it! JBehave 2 has only been live for a few days and already ThoughtWorks colleague Ryan Greenhall has written an excellent tutorial demonstrating how to use it. Quoting the release announcement on the site, JBehave 2 supports the following feaures:
Go download JBehave 2 and take it for a spin, and let me know what you think. The mailing lists are waiting for you too.
1. Aslak Hellesøy is currently working on a replacement for the rspec scenario runner called Cucumber which looks very promising.
Should examples/tests/specs/whatever be DRY(Don’t Repeat Yourself)? I’ve been thinking (and talking and arguing) about the value of test names recently and whether they are just unnecessary duplication, but that’s the subject of a future discussion. This is about the actual content of your examples. So, should your examples be DRY?
In a word, no. DRY zealotry is a classic example of an over-adherence to Best Practices, which as James Bach argues are a bogus concept anyway. When you are writing software, including executable examples, your focus should be on clarity of intent. If the code could be any more obvious, you’re probably not done yet. And given that code is created once but read and changed many more times, it is healthy to develop a strong sense of responsibility to the guys coming along after you.
The DRY principle says that the definition of any concept should appear once and only once in your code. This is an admirable aim in that if you have to change the behaviour of a Flooble, you want to be able to change it in one place and be reasonably confident that your change will apply consistently across the codebase. If there are multiple definitions of a Flooble, the chances are that not only will you not catch them all, but that someone before you didn’t catch them all and the multiple definitions are already inconsistent, and who wants that?
However, when you are using examples to drive your code – a process I call Coding By Example but which most other people insist on calling Test-Driven Development – there is another principle in play that I believe trumps the DRY principle. The examples tell a story about what the code does. They are the documentation narrative that will guide future programmers (including yourself when you come back to change this code in three months time and you’ve forgotten what it does). In this case, clarity of intent is found in the quality of the narrative, not necessarily in minimising duplication.
Some years ago I had my first experience of pair programming with Martin Fowler. That is, I had done quite a bit of pair programming, just not with Martin before. We were looking at some ruby code I had written test-first, and Martin asked to see the tests, “to find out what the code does”. Then he did a rather odd thing. He started moving the tests around. I had a few helper classes and utility methods in the source file, neatly at the end out of the way. He moved them up and dropped them inline just ahead of the first test that used them.
Madness! I thought – now the supporting code is all over the place! It really offended my sense of tidiness. But then I saw a pattern beginning to emerge. The test code was starting to read like a story. He would introduce these little methods and classes just before their one walk-on line in the narrative. It was quite an eye-opener for me. The test code flowed, and unfolded the story of the class under test. (I know I’m using TDD vocabulary – this was in my pre-BDD days.)
The A-ha! moment for me was when I imagined reading a story book where the plot and characters had been DRYed out. Everything would be in footnotes or appendices. All the character descriptions, plot elements, subtexts etc. would be carefully extracted into fully cross-referenced paragraphs. Great if you are “reading” an encyclopaedia, not so appropriate if you want to get into the flow and find out what happens. You would be forever flicking back and forth in the book and you would very quickly forget where you even were in the story. In the words of the old joke, a dictionary has a lousy plot but at least they explain all the words as they go.
So here’s my challenge to you. When you read through a test case, or spec file, does the story unfold? Does it start by introducing the object’s most important responsibilty? Does it then introduce the edge cases in descending order of priority? If the test uses helper classes and methods are they tucked away at the end, or worse yet in an entirely different file that I am expected to “just know” is there?
Try to avoid using before blocks or setUp methods – especially in an abstract test class. Just call the method that does the setting up directly from the example. Don’t leave me to guess there might a magic method in a different class that is being invoked before the test even runs – that’s just not fair.
Also thanks to Mikel Lindsaar from the rspec mailing list for an excellent article about the perils of slavishly following DRYness.
[mikel]http://www.lindsaar.net/2008/6/24/tip-24-being-clever-in-specs-is-for-dummies
I was in a hotel in Stockholm recently and I noticed a bottle opener attached to the wall in the bathroom. There was a bilingual sign under it which got me thinking about the term “bottle opener” itself. (I was giving a talk about BDD the next day so I was already thinking about how language is used.)
It occurred to me that “bottle opener” is a great example of goal-oriented vocabulary. The device itself is actually a cap remover, and it only works on one particular design of metal cap. The reason I use it, however, is to enable me to get to the beer in the bottle. Hence “bottle opener” rather than “cap remover”.
There is more to this than just linguistic curiosity. If you use task-oriented vocabulary it can cause you to focus on the means rather than the goal, which in turn can limit your options. My favourite example of this is the term “search engine”. Searching is the activity I have to do because I’ve misplaced my keys and I’m locked outside. What I want is a find engine!
Google realises this. When I type something into Google, it guesses what I’m likely to be trying to find, not what I happen to be typing into the box. If I type in “Stockholm map”, I’m likely to be looking for a map of Stockholm (first three results are actual maps – presented as pictures) or some information about the town itself. If I type “hotels Stockholm” I’m probably planning a trip there and voila! lots of useful results for the traveller. Other “search” engines do just that – they search, and produce lists of results. It’s then down to me to sift out the ones I care about to get me closer to my goal.
We talk about “focusing on a problem” in order to solve it. This is a task-oriented phrase. An alternative would be to stand far enough back that you see the problem in its proper perspective. If anything you are “blurring” on the problem – deliberately losing focus on the detail to see if any larger-scale structure emerges.
I often describe BDD as outside-in development. You start at the outside with an automated scenario, and work inwards, discovering services and collaborators as you go, until you’re done. With a legacy application it can be difficult to remain outside enough, or to get a good enough frame of reference for “done”. Blurring can help with this.
For the last six months I’ve been involved in restructuring and re-architecting a legacy code base. It’s been quite a major undertaking, and has involved a number of false starts and dead ends. (I’m planning to write it up as an experience report at some point, but given my current throughput of things I plan to write, don’t expect it any time soon.) During this project, I’ve often found myself struggling to choose between alternative strategies, or unsure of where to go next. In these situations I’ve found that stepping back and “blurring” gives me enough perspective for one of the alternatives to become “obvious”. In fact a couple of my teammates have picked up on this and will actually suggest it as an activity when we are pairing. “We’re thrashing here – let’s step back and start from the outside again.”
It could be as simple as asking “whose responsibility is this feature?” or “who is the actual client of this method call?”. You don’t need to know the answers – just verbalising the questions can give you enough “blur” to gain a better perspective.
Linus Torvalds recently gave a talk where he said the problem with source control isn’t branching, it’s merging. Again, by taking a broader perspective – in this case temporal rather than spatial – his insight is that the goal is a successful merge some time in the future, not the task of branching now.
As a final thought, while I was thinking about this I realised the term “behaviour-driven” contrasts with “test-driven” in a similar way. My goal as a developer is to deliver a system that behaves in a particular way. Whether or not it has tests is an interesting metric, but not the core purpose. “Test-driven” development will cause me to have lots of tests, but it won’t necessarily get me nearer the goal of delivering business value through software. So you can use goal-oriented vocabulary in your development process as well as your code to help maintain perspective on what you are trying to achieve.
_Props to James Lewis for helping me formulate these ideas. And for being really good at perspective._
