Once upon a time, you probably didn’t write any tests. We know, we’ve been
there, it’s not a happy place, but we all start somewhere. Eventually, you
started writing some tests, and even read about or tried “Test-Driven Development”.
The idea is simple, write your tests first, and then write code until your
tests pass. It helps clarify your goals before you spend time developing.
You also know that as soon as your tests all pass, you should stop working!
This makes it harder to over-perfect your code.
Behavior-driven development, or BDD, is the next evolution. It’s similar to
TDD except that instead of writing tests first, we’ll create written descriptions
of the behavior of a feature. Dan North - the father of all of this
BDD stuff - once wrote that ‘Behaviour’ is a more useful word than ‘test’.
Of course! Writing tests is great, but before we do any work, we need to understand
the exact behavior of the feature we’re building.
There are two styles of BDD - SpecBDD and StoryBDD. Roughly speaking, Spec
is used for writing unit tests. In PHP, a wonderful library called PHPSpec
exists to help with this style. In this course, we’re talking about the other
type, StoryBDD, which is typically used for functional testing. In an ideal
world, you’ll use both styles.
If nothing else, BDD aims to solve the great problem of communication. Every
project has a lot of players: developers, a client, project managers, velociraptors,
pterodactyl and Samuel L. Jackson. As computer scientists, the development process
is usually a bit of a goat rodeo, where nobody really understands the full goals
or behavior of what’s being built.
BDD aims to fix this by giving us a standard language for describing these
features. We’ll also follow a workflow that will help make the whole process
from “great idea” to development much more sane:
Define the business value of the features
Prioritize features by their business value
Describe them with readable scenarios
And only then - implement them
As a developer, this might look like boring business-talk. But I’ve used this
countless times to break a big idea into smaller pieces written in clear language.
And for a developer, getting clear directions rocks!
Ok, all the theory is behind us, let’s get to Gherkin, the language of BDD!