Acceptance Frameworks Vs. Specification APis
Historical article · Originally published March 29, 2013; technical details may be outdated.
I see two forms of ‘BDD’ tools floating in the wild.
The first form, let`s call it ‘deep BDD’ for now, requires you to go through a special langauge filter, before translating it with special adapters into executable specifications. Think Cucumber’s Gherkin forcing you to write adapters in code to execute your tests. Or SpecFlow’s Gherkin with .NET step definitions.
The second form, let’s call it ‘shallow BDD’ are tools that only give you an API to develop with, but no natural language interface to discuss with end users, or for giving end users to edit on their own. Think RSpec, MSpec or NSpec – they are literally just libraries that allow you to write your “tests” in a more BDD like API.
Deep BDD tools give you more permission to get out of your comfort zone and talk to a customer, while shallow BDD tools give you more permission to stay in side your comfort zone – your code, and to just stay with yourself, coding into the night, not having to talk to anybody, still feeling you’re awesome because you are dong ‘BDD’.
In that way, shallow bdd tools are just shiny wrappers on unit testing tools, while deep BDD tools make us work harder for communication.
3comments
Comments from the original blog, kept for the record. Commenting is closed.
to me deep BDD tools help u writing 'tests' that are easier to understand ... n' since they r fairly decoupled from code they allow thinking/designing or expressing before u start geeking out in code
Not sure I agree with this.
We use https://github.com/xbehave/xbehave.net and we have a rule that all scenarios are written in Gherkin in our story definitions and agreed with the client. We then lift these scenarios and place them directly into xBehave.net scenarios.
I guess you would class xBehave.net as a 'shallow' framework because we don't have to write a mapping layer? I see not having to write a mapping as a benefit. Having the scenario directly in code makes it much more transparent and easy to browse, but we still have the scenarios written in Gherkin and written, effectively, by the client.
My impression is similar and when I think about Gojko's Adzic Specification By Example process, the step where the two "genres" differ the most is "Automation without changing specification".
After this step, one could argue, the process can be the same with both kinds of tools, because e.g. NSpec tests, when written properly and run, are able to produce business readable output that can be used as a "living documentation".
Before this step, one could argue, we don't actually require any automation tools.
It is during the transition from analysis to automation that the specification frameworks really stand out, because e.g. Gherking (or annotated tables, as in FIT), which is required by those tools, is so close to natural language yet structured, that it can be used successfully during analysis and discussion.
By the way, a somehow hybrid approach is StoryQ, which consists of a library & API that can be used with e.g. NUnit (so we can start writing our scenarios in code straight away), but at the same time, provides a tool to convert Gherkin-like scenario description into a template that can be copy-pasted into code and filled in.