Or how programmers and testers can work together for a happy and fulfilling life.
Why don’t we just automate all the testing? Is test coverage a useful metric? What does it mean to “shift testing left”? When and where should we be testing? How much is enough testing?
My friend Gojko Adzic has been running a series of BDD quizzes illustrating different ways to approach some interesting BDD situations. I noticed on Twitter that Seb Rose, another BDDer (Cucumberer?), had gently taken issue with one of Gokjo’s solutions so I thought I’d take a look at them both. Before reading on I recommend reading Gojko’s solution and Seb’s response for context.
tl;dr: Send us your examples of real world BDD. Read on to find out why.
“What is BDD?”
“How can I tell if I’m ‘doing BDD right’? Or wrong? Is there even such a thing?”
“Where should I start?”
“Is this or that practise considered part of BDD?”
“What are the mandatory ”core“ practises of BDD?”
These and similar questions were the topic of the closing panel at the recent CukeUp conference in London.
A question came up on the BDD list recently, and based on feedback I thought it would be useful to post my answer to a wider audience.
I’ve noticed a number of people recently declaring that BDD really is just TDD, such as Robert Martin on Twitter and Ron Jeffries on the XP list. I can understand where this mindset comes from and I’d like to offer my perspective.
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.
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.
I am delighted to announce the official Japanese translation of Introducing BDD.
I’m delighted to be taking part in a In the brain of… session organised by the folks at SkillsMatter.
A friend of mine has a Far Side desk calendar that he describes 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.
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.
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.
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?
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”.