I was talking to Pedro Santos on the train the other day. Pedro is my technical lead, an expert in his field and a keen advocate of automated testing and software craftsmanship in general. We were talking about Gherkin and Pedro was saying he doesn’t see Gherkin tests adding value because it doesn’t help him as a developer. Of course I disagree. The way I look at it is the Gherkin tests are not for the developers. The Gherkin tests are for the organisation – they are for everybody.
The Developer perspective
Everybody looks at the world through a filter lens. Developers have developer glasses. Nothing wrong with that but it does impact what they value.
Dan North noticed this in the BDD == TDD debate (see BDD is like TDD if …). Developers don’t see much difference between BDD and TDD and so don’t see much value in BDD, particularly if they work in small developer-only teams. Dan explains it like this:
BDD is the same thing but for a broader audience: testers, analysts, project and program managers, multiple SMEs covering multiple interrelated domains. It’s interesting that the BDD == TDD crowd are entirely programmers and necessarily see the world through programmers’ eyes: Bob Martin, Ron Jeffries and others saying “BDD is just TDD” is true in the first approximation of “all delivery people are programmers.” As soon as that precondition fails, BDD becomes a different, bigger thing: it becomes the communication across all of those stakeholders to create a single coherent vision and deliver to that. This is the value of living documentation – and shows why you don’t need it until you do: if you’re in that small team of only-programmers you’ll be fine with only-TDD.
. . .
in the kind of organisations and teams that gave rise to and shaped BDD we have to solve the more complex communication problems that are (by definition) beyond the scope of TDD.
I extend this observation to the types of tests that go with BDD and TDD.
Who are Unit Tests for?
TDD is a test first process wrapped around unit tests. I believe unit tests are automated tests for developers by developers. They test classes and methods within a class. Really low level stuff.
Unit tests are really important and I advocate developers doing them. However they are also really uninteresting from my perspective as a programme manager.
Even if you scale these tests up a bit to be what Pedro calls integration tests – tests that span classes but still within an unit test framework – they are rather uninteresting to anybody except the developers. Nobody looks at them except developers. Tests for developers by developers.
Who are Acceptance Tests for?
In contrast acceptance tests, written as Gherkin scenarios for a tool like Cucumber, are for everybody. These scenarios are a way to Specify by Example in a domain specific language based on natural English. That makes the scenarios a very effective communication mechanism. The 3 Amigos meeting is a formal opportunity for this communication but there are others.
Some argue that the communication that comes with BDD and Specification by Example is more important than the automated tests themselves.
Unit tests are great but they cannot provide this level of communication.
References
North, D. (2012, 31 May). BDD is like TDD if …. Author.