The cornerstone of BDD, short for Behaviour Driven Development, is the idea of a shared language used throughout the team to write and tests business requirements. In particular BDD recommends that tests should be written:
- … before the production code is written. Which is fine, recommended even.
- … in a ubiquitous language that is understood by all members of the team. This means expressing tests in text format using natural language constructs. And there lies the problem(s).
What’s wrong with expressing tests using natural language ?
1. An extra layer of code is required to translate between the business-readable tests and the developer-readable production code. Often this is accomplished using a “framework” (shudder) such as JBehave or Cucumber. This translates into more code to write, more dependencies to add into the project and more opportunities for bugs. Plus this slows down debugging as code paths have to be traced through that same translation layer.
2. BDD are best suited for end-to-end tests, i.e tests which involve testing the system end to end, from initial input to expected output. End to end tests tend to be fragile, slow and take time to write. Every effort should be made to restrict end to end testing to only a few select, critical use cases while everything else can be addressed with unit tests. BDD encourage just the opposite.
Suggested ratio between end to end tests and unit tests should look like the pyramid below with few slow, brittle end to end tests and many fast, reliable unit tests.
3. Last but not least… nobody looks at the output produced by BDD tests. And especially not product owners and/or testers, so business readable tests will be lost on them. When it comes to verify the behaviour of the system they will instead fire up the application under test, manually reproduce a scenario and visually scan for the result. It’s so much simpler and quicker compared with looking for the BDD tests output and then trying to ascertain how exactly the steps described map to application functionalities.
So in summary. The core tenet of shared artefacts certainly is interesting in theory however in practice it does increase code complexity and turnaround time. One redeeming feature at least is that BDD nudges the team into writing *some* end to end tests (as long as they’re kept under control as the test pyramid above illustrates).