Background

I attended the STC Meetup in Birmingham on Tuesday evening and was struck by a realisation towards the end of Simon Knight‘s lightning talk on the pros and cons (they were mostly cons) of Cucumber. More on this epiphany later…

By happy coincidence I had recently started to look into Cucumber as a concept because our development team on the SAMS Programme here at Nottingham are trying to move towards embracing continuous integration as a methodology. I have read and digested the Cuke4Ninja how-to PDF and it seems, on the surface, to be addressing some of the failings of “traditional” software development. Its main thrust is the use of Gherkin, a form of Structured English, to enable requirements specifications, or derivations thereof, to be put forth in much tighter and more precise terms than are commonly used. Bluntly the idea is that by aiming to reduce ambiguity, better software will result faster. Riding on the coat-tails of this are programming language libraries (Cucumber is by far the dominant one) to make Gherkin statements executable and thus testable in some limited sense.

Criticism

With good timing James Bach (also at the Meetup) had recently weighed in with some strident criticism of the Behaviour-Driven Development (BDD) methodology that Cucumber is a tool for.

Realisation

I realised during Simon’s presentation that Cucumber tries to position itself at the intersection of Analysis, Development and Testing (visualise a Venn diagram of these roles) and is therefore essentially a compromise between all three.

To quote from Cuke4Ninja (page 13 of the PDF):

Cucumber is a functional test automation tool for lean and agile teams. It supports behaviour-driven development, specification by example and agile acceptance testing. You can use it to automate functional validation in a form that is easily readable and understandable to business users, developers and testers. [my emphasis]

The point I raised during the Q&A was that since each group already produces their own form of documentation particular to their viewpoint (Business Analysts write requirements specifications, Developers have their code, Testers produce test plans, etc) how can any documentation possibly sit between all three and not be compromised? Who would author such documentation? Who would own it? And who would realistically countenance adding what would be a fourth layer to the mix when documentation is hard enough to do anyway? It is yet another set of documents to be kept in synch with the true requirements, which are hard enough to ever nail down.

Caution

If BDD is half of what it’s cracked up to be, such an investment might be worthwhile. There are some interesting concepts there and not all are without merit. But it is the nature of people to overstate the worth of something new so we need to exercise caution while at the same time being open to new ideas. I’m reminded once again of Fred Brooks’ paper No Silver Bullet which still stands as an undefeated caveat to the entire software industry 25 years since it was published.

Futher Work

I leave you with these notes I jotted down after the session. Despite the scepticism above, I still intend to do this, though I admit my enthusiasm has been somewhat tempered:
Cucumber/Gherkin
– learn it
– apply it
– report on your experiences
– bask in the warm glow/icy frost of your peers

Watch this space.