We now have this knowledge made explicit and stored in svn.

This stuff is real, and it works!

Where troll-like became troll was with point 6, which is the subject of your response: “Don’t use Cucumber unless you live in the magic kingdom of non-programmers-writing-tests (and send me a bottle of fairy dust if you’re there!).”

First, he called out Cucumber, not JBehave, FitNesse or any other tool, but he’s talking about “non-programmers-writing-tests” in general. Troll!

Second, as George pointed out, it’s not who writes the examples that is important – it’s that there’s an increased level of communication between dev, test & business.

And finally, I think we do ourselves a dis-service if we accept (even in jest) that there’s pixies, magic or any other flavour of faith involved in developing good software.

Just say no (to the dust) & brew yourself another cup of tea.

From https://github.com/cucumber/cucumber/wiki/Step-Definitions “Some people are uncomfortable with Regular Expressions. It’s also possible to define Step Definitions using strings and $variables like this:”

In my experience, it’s not very important for BAs to write gherkin. It’s not important for them to write the examples down at all. Communicating them to someone who can write them in a form that works is just fine.

It is, however, important that they can read them. Having someone else have to tell them what the tests mean is a problem.

If it can be easily marshaled to plain English, it can be easily discussed.

Put another way: coding in pseudo-English is a red herring.

This example team went from the painful fiddly annoyance that is cucumber (which as you say has some potential benefits that may or may not outweigh that annoyance) to… nothing? No tests at all? No planning, no bug reports, no QA team working to find issues… nothing?

Sorry to say, but these people are just a crappy team that were using BDD as a crutch to help them not suck. SOME teams are capable of not sucking no matter what process they use. DHH likes a regular, sane “test in a way that gives me confidence in my code base and ability to make future changes” testing methodology. Don’t act like cucumber/BDD is the only way to do this.

While “bridging the communication gap” is very important, cucumber is not an ideal mode of transport:

• Gherkin language is too restrictive. How many times have I found myself correcting ‘incorrect’ BA’s steps? Many, many times. What if they were just writing them in English? One less translation level. Exactly what is needed for better communication;

• Regex dispatching is a terrible idea. Classic showcase for ‘Have a problem? Use regex. Now you have two problems’

• The whole ‘reuse step’ idea is flawed. If you want to reuse, the underlying language (ruby, java, etc.) provides much better tools to do that (packages, classes, modules, etc).

Having said that, I am using cucumber both at work and for personal projects… But I am not happy with it! 🙂

DHH’s points are valid if tests are just a way to check for bugs, but that’s an extremely immature view and use of TDD. That’s like novice-level TDD. TDD is a design tool.

I use Cucumber and TDD on every project. It saves me a ton of development time, a ton of potential requirements misunderstandings, and a ton of tight coupling. I can’t imagine how slow I’d be without it.

I recently embarked on a new project bringing the ease of use that RVM brings to Ruby developers to the Groovy community. So, GVM was born (http://gvmtool.net)

From the outset, I chose to collaborate with my fellow developers by fleshing out our features in Cucumber’s Gherkin syntax. We used concise examples of how the tool should function on the command line, then implemented the behaviour as an outcome. All the scenarios for the project so far can be found here for all to see and collaborate on:

https://github.com/gvmtool/gvm/tree/master/src/test/cucumber/gvm

At this point the tool is alive, well and growing rapidly. It’s continually improving as new features are added or existing ones challenged. It might not be a big kingdom yet, but it’s magic nonetheless!