There is no silver bullet

Aaah - back from the post-technical

BDD vs Cucumber

There seemed to be lot of confusion around BDD among people at #cukeup.

There where a lot of testers at the conference, and while Cucumber runs tests, that’s not all it’s about because BDD is not about testing.

So what is it? and where does Cucumber fit in?

What is BDD?

I first came across the term in 2005 while I was working for ThoughtWorks.

Dave Farley brought it up during the morning stand-up and mentioned that Dan North was about to publish an article on it and it was going to be important.

A couple of things he said about it caught my attention.

It’s the bastard son of Test Driven Development and Domain Driven Design

and

It’s the nearest thing you’ll find to a silver bullet

I really liked the first statement, this was exactly what we needed.

I liked the second statement too but the most important part of it is “nearest thing you’ll find”. It’s not actually a silver bullet – there are none – hence the title of this blog.

Don't let them stop you refactoring

My simple advice on this is simple – don’t tell them.

If you let your product owner decide when a piece of refactoring work needs to be done, they will never prioritise it. the product owner’s job is to maximise the value delivered, and refactoring doesn’t directly produce value.

Bad code and bad design are not visible outside the development team

However the effects certainly are visible. Velocity gradually dropping off over time, an increase in the number of bugs and estimates for new features getting larger and larger.

Just factor the time in with your normal dev tasks. I’ve always taken the view that quality and maintainability are implied features of any software I’m working on. It’s the responsibility of every developer to keep the code clean and maintainable.

Even if everything is green and the feature is complete, unless you are happy with the design – you are not done. Even if someone else made the mess – you are still not done.

If you don’t refactor, how do you know that you can refactor. By refactoring relentlessly, you can be sure your codebase is agile, if you are constantly having to refactor your specs, are they too low-level.

The advantage of BDD’s outside-in approach is that it’s easier to take a pragmatic decision, on a spec-by-spec basis, which level of granularity is best for the behaviour you are interested in.

Pair-programming also helps with spotting code smells. If you are not pairing, you at least do code reviews need to get a second opinion, proof-reading, if you like, to see if someone else can read your code. If not you need to do a bit more refactoring.

How not to use Cucumber

Business Facing?

I’ve seen some horrible Cucumber scenarios in recent years. Some of the worst examples look like this (except much worse).

Scenario: Sucessful user registration
When I go to the user registration page
And I fill in “user_name” with “Joe Bloggs”
And I fill in “user_email” with “joe@bloggs.com
And I fill in “user_phone” with “+44 4444 4441”
And I click “#commit”
Then I should see “You have signed up successfully”

Notice the element ids in here – this is not uncommon.

Even your testers will have little interest in scenarios written like this, if you show them to a BA, or even worse one of the project’s stakeholders, they will think you are mad.

Why would they be interested in a test? Why would they be interested in such a trivial feature?

Does this scenario even need to exist?

What you are showing them is a test, and BDD is not about testing.

When not to use Cucumber

I can sum this up in a couple of bullet points:

  • When it should be a unit test
  • When nobody outside the delivery team cares about it

When it should be a unit test

The value of automated scenarios are at their highest while the features are still being delivered. Particularly in areas where you need to have a lot of discussions with your stakeholders.

Once a feature has been completed, the scenarios still have value as regression tests, but is not really necessary to have all the behaviour defined in Cucumber.

After delivery of each feature, there should be a comprehensive suite of class level specifications. Any business rules ought to be covered by these and therefore shouldn’t need to be tested again by Cucumber.