HN Explorer

Ask HN: BDD and Gherkin tests, do they provide value in the real world?

2 points by floppydisc ↗ HN
Recently stumbled upon BDD and the process of describing software from behaviour. I know there are seriously prolific software engineers amongst the Hacker News crowd and I could use a second opinion from within the industry.

What are your thoughts on BDD in general, with everything included (Gherkin, Cucumber etc.). What benefits have you yourself experienced (if any) or perhaps disadvantages of such ideas?

5 comments

[ 3.0 ms ] story [ 20.5 ms ] thread
breckenedge
I last gave it a good try about 12 years ago. In principle I liked it, but in practice it’s fairly verbose and slow. I much prefer Cypress/Capybara style testing.
floppydisc
Why do you prefer Capybara style testing to the Gherkin style testing? Is it primarily the conciseness?
hitchstory
I like the overall idea a lot but I felt that the Gherkin language itself hamstrings the process - for four main reasons:

* Excessive verbosity

* Not type safe

* It lacks story abstractions (i.e. you can't flexibly create variations on a scenario, extend existing scenarios, etc.).

* You need to fiddle with regexes.

A side effect of these semantic/syntactic problems is that gherkin stories end up being too vague to be useful - i.e. the meat of the story is often missing.

I created a StrictYAML based alternative with python that I think has all of the benefits, fixes those 4 problems and doesnt suffer from traditional "YAML" problems: https://github.com/hitchdev/hitchstory

I call this "BDD with meat".

floppydisc
Interesting, I'll check it out.

One of the arguments, as far as I understand for the BDD verbosity is that fact that the requirements are easy to communicate with customers and so therefore would be more precise in going from defining requirements to actually building the right thing. How true do you find this?

hitchstory
Verbosity is good for explanatory documentation but it inhibits the maintainability and editability of a spec.

Cucumber essentially treats documentation and specification as equivalent, while hitchstory treats documentation as a more verbose and readable artefact that can be autogenerated from a combination of a spec and a template.