Transcripted Summary
Before we dive into BDD and the 3 stages of the textbook BDD process, let's have a look at some of the most common misconceptions that people have about BDD.
# Misconception 1: BDD is a testing activity.
First of all, BDD is not a testing activity.
While testers and testing play a pivotal role in the BDD process, BDD is an activity for the whole team. It revolves around communication and making sure that everybody is on the same page with regard to the expected behavior of a new Feature or of a new software system
# Misconception 2: BDD is all about test automation.
Second of all, BDD is about much, much more than just automating acceptance tests.
I see a lot of people and teams claiming that they are practicing BDD when all they do is stick in a Gherkin layer on top of their predefined or existing test automation code.
That is not BDD.
That is sticking a Gherkin layer on top of your predefined or existing test automation code.
While tools like SpecFlow are very powerful and can bring a lot of value to your software development process, the true power of BDD is in communication and having meaningful conversations about what the software that you mean to develop is supposed to do.
SpecFlow and automated acceptance tests can help you verify afterward whether or not the software you built conforms to the specifications and the behavior that you defined and discussed before starting development, but it's definitely not the only part of the BDD process
# Misconception 3: BDD will solve all of your problems.
Third of all, BDD is not for everybody.
While it is a very powerful methodology that can help you clear up misconceptions and misunderstandings about how software is supposed to behave as early as possible, it might not work for everybody. And it might not work in every situation or for every context.
Just like Agile, Scrum, and Kanban, BDD is a methodology, and methodologies tend to work better in some contexts than in others.
So, before you decide to do a full-blown BDD implementation, please make sure that it is the right methodology for your team and for your context.
For example, by doing a proof of concept or by running a pilot project with a development team of your choice.
# Misconception 4: There’s only one right way to implement BDD.
Finally, as with any methodology, there is no one right way to do BDD.
I like to present BDD as a toolbox, a set of tools and principles that you can adapt to your own context and your specific needs. So, pick from the BDD toolbox what works for you, what fits your context, your team, and your organization, adapt that as you see fit and leave out or stop using what does not work for you.
Don't be afraid to experiment!
# The “Textbook” BDD Process
Having said that, there is such a thing as the textbook BDD process, and this textbook BDD process consists of 3 separate stages.
In this course, we'll go through all 3 of the stages, and we'll take the Feature that we want to add to our online banking system through each of these stages.
Of course, before we even start working on a Feature, we should have some level of confidence that that Feature is going to add value to our product, to our process, or maybe even to both.
The first stage of the textbook BDD process is called Discovery.
This is where the important conversations take place. This is where we come up with examples that illustrate the desired behavior of our software.
And this is also where we create a shared understanding where we make sure that all the stakeholders within our development are on the same page regarding what our software should and should not do.
The second stage of the textbook BDD process is the Formulation stage.
This is where we take our examples and we turn them into specifications that document and illustrate the requirements and the expected behavior of the Feature or system that we're building.
Automate Acceptance Tests
And in the third and final stage of the textbook BDD process, we're going to turn these requirements into executable specifications and living documentation.
Or in other words, we are going to create automated acceptance tests, using tools like SpecFlow, to automatically verify that the software that we have built conforms to the specifications and to the behavior that we defined and discussed earlier in the process.
In the next couple of chapters, we are going to look at each of these stages of the BDD process in more detail, using the planned “LoanApplication.feature” of our online banking system.
