[ad_1]
These days, folks keep asking me an uncomfortable question: “Is BDD dying?” Behavior-Driven Development has been around for about twenty years, but recently, it feels like the movement has stalled. Is BDD dead? Are we really at this point?
NO! Heck no. Not if I have anything to do with it. But I’ll be honest, we have some work to do to set things right. BDD needs to evolve. Let’s cover the story of what happened to BDD, what are the good things we should preserve from it, and how we build a better future on behavior-driven principles.
The Core Principles
Let’s start by defining Behavior-Driven Development. I’ve always defined BDD as a set of helpful practices to help you put your primary focus on the behaviors of the software that you are developing. Not on the code, not on the tools, but on the actual functionality of the product. Why? That’s what your users do! If we focus on behaviors first, then everything else falls into place.
Ultimately, behaviors matter more than code. Users don’t care if you wrote your app in JavaScript or Python. They don’t care if it’s running on Azure or AWS. They need your app to solve their problems. To get things done. To do their jobs. You can have the best code in the world with 100% unit test coverage and a perfect Agile process, but it doesn’t matter if the behaviors of the software product itself don’t deliver any meaningful business value.
If we want to prioritize software behaviors, then we should ask ourselves a few important questions to shift our thinking:
- What if we tested behaviors together with the code? Both are important. It helps to have developers and testers on the same page.
- What if we described behaviors in plain language rather than in cryptic programming languages? Software is meant to be used by people. If we can’t explain how to use it in plain language, how will anybody ever be able to understand it enough to use it?
- What if we defined all these behaviors before ever touching any code? We could resolve many design issues before committing the time to code it. We would also have an agreement on what should be built that we could use to hold the team accountable.
- What if all the different roles on the team – business, development, and testing – all collaborated on these behavior specs? Multiple perspectives bring valuable insights into product development that ultimately contribute to higher quality and greater value.
- What if those behavior specs that the team writes together could be automated directly with special tooling? All those specs essentially become test cases. We could set up continuous feedback loops to tell us if we are building the right things and if they are working. The specs become Living Documentation.
And that’s how BDD was born! BDD is an orientation towards business value. It became a set of practices to help people focus first on behaviors and second on implementation details. People may love or hate the outcomes of the movement, but I don’t think anybody can rightfully disagree with the premise.
A Concise History
The first major BDD tools were test frameworks. They appeared in every major language by the early 2010s. Many of you have probably used one of these frameworks. The most popular one was Cucumber. My favorite was SpecFlow – a masterpiece of “automationeering.” Almost all other BDD test frameworks are derivatives of Cucumber.
The early 2010s were truly the Golden Age of BDD, a time of flourishing and growth. Teams around the world started embracing it. Engineers integrated BDD frameworks with tools like Selenium WebDriver and Jenkins. Design patterns like the Screenplay Pattern arose. There was this incredible outpouring of new, exciting stuff!
BDD’s secret sauce was Gherkin. I’m sure almost everyone has seen Gherkin’s Given-When-Then steps. Its beauty was its simplicity. Folks could read Gherkin scenarios and immediately understand the intended behavior without worrying about all the implementation details.
Since all the BDD frameworks required testers to write their tests in Gherkin, the world came to see Gherkin as a domain-specific language for test automation. The frameworks naturally separated the “what” of the test from the “how.” Testers also realized how effective it was to write steps once and reuse them in any test.
Alas, BDD’s golden age did not last forever. What ended it? War – primarily fought over Gherkin. Many folks like myself recognized how a programming language for test automation could make tests much easier and faster to automate. Others, however, hated writing an extra layer of steps above their test automation code. They felt like it was completely unnecessary, making tests slower to write and code less “clean.”
Meanwhile, many of the original leaders of the BDD movement felt horrified that teams would use frameworks like Cucumber without cross-role collaboration over behaviors first. They also saw how BDD became pigeonholed as a testing activity.
Many of these leaders reacted by focusing more on the collaboration side of BDD than the automation side. Good things came of this, such as the practice of Example Mapping. However, I believe the pendulum swung too hard the other way, almost to the point where many leaders practically shunned automation, discrediting the value in a language for testing apart from collaborative practices. Unfortunately, this meant that the “thought leaders” and the “trench workers” were heading in opposite directions.
Regardless of disagreements, BDD became very popular throughout the software industry. By the end of the 2010s, testing tool vendors took notice. SmartBear bought Cucumber, and Tricentis bought SpecFlow. Initially, there were high hopes. The new owners started investing in building BDD tools beyond the classic test frameworks. BDD was having its moment. Personally, I loved SpecFlow’s LivingDoc generator.
What Happened?
Things have been rough for BDD the past few years.
Test tool vendors failed to commercialize BDD tools and ultimately gave up on them. I don’t know exactly what happened or why. All I know is that SmartBear gave Cucumber to the Open Source Collective, and Tricentis literally just shut down the entire SpecFlow project. Thankfully, Gaspar Nagy forked SpecFlow and rebranded it as Reqnroll. Nevertheless, seeing major test tool vendors move on from BDD tools sent a bleak signal about their future.
In that, we as an industry failed to successfully productize tools for collaboration. The world jumped on BDD because Cucumber-esque frameworks were easy to adopt. The world was less willing to adopt BDD’s collaborative techniques because they were merely processes, not products. Products are sticky; processes are not. Cucumber tests will still be running after we all retire.
The testing world also moved on. Exciting new tools like Cypress and Playwright came out. Then AI became big. Folks just aren’t talking about BDD as much.
Speaking of AI, LLMs made Gherkin feel old and clunky. Gherkin enables folks to write their specs in plain language, but the steps they write must be written perfectly and identically every time. In large projects, it becomes difficult to find the “right” step. Tools using LLMs let users write free-form steps and then figure out what the users meant. They are more user-friendly. They “do what I mean” rather than “do what I say.”
And finally, the movement itself slowed down. There is still good work happening, but from my perspective, it is not as groundbreaking as the golden age. We haven’t seen many new things. The movement feels like it has stalled, especially post-COVID.
Deep Thoughts
I’ve thought about this a lot. A LOT. The principles of BDD are still valuable. In fact, I think they’re more applicable than ever. As a software industry, we continue to flounder through the same problems. I’ve also realized that the tooling doesn’t match the principles. As a movement, we haven’t productized aspects of the process in ways that help people improve their software development practices. We haven’t seen advancements to the same degree that we saw during BDD’s golden age of the Cucumber patch.
I’ve been asking myself two questions:
- What “Behavior” could be?
- How could we provide better tooling for it?
I think Artificial Intelligence technologies could help provide much better tooling. If used appropriately, it could remove many points of friction in the development process. AI would not replace product owners, developers, or testers but rather empower them… and perhaps even coach them into better practices. I can’t help but think about what BDD would have looked like if it had technology like LLMs from the start.
I’ve also come to realize that the “intelligence” itself is not artificial. It’s just regurgitated from existing sources. We can bake what we already know into it. The challenge then is not merely prompting it with the right queries. The challenge is delivering the insights it offers in a way that seamlessly becomes part of the greater development experience. So, rather than “artificial” intelligence, what we truly need is…
Automated Intelligence. We need insights to automatically come to us as we are developing software. We need coaching to help us stay oriented on behaviors. We need agents to take care of grindwork like organizing the artifacts of our process, running tests, and analyzing results. Intelligence doesn’t always need to come from heavyweight technology like LLMs, either. Sometimes, it can be as simple as an extra comment inserted into a spec or a rote question asked by a chatbot.
I think the notion of “automated” intelligence fits perfectly into the BDD process. I first learned about the process from Seb Rose and Gaspar Nagy in The BDD Books. There are three phases: Discovery → Formulation → Automation. This process frames software development into one seamless, cohesive process that focuses on behaviors through and through.
Let’s walk through these phases together.
A Renewed Process
Discovery
Discovery is the first phase. It is an activity of learning. In Discovery, teams are figuring out what the business-critical behaviors should be.
To be truly successful, teams need Cross-Role Collaboration to gain insights from all perspectives. This has commonly been referred to as “The Three Amigos” of business, development, and testing, but I prefer to think of it more broadly as cross-role collaboration to account for multiple people in those roles as well as people in other roles such as UI/UX design.
To be productive, teams engage in Structured Activities to make sure their meetings produce meaningful artifacts that move development forward. Structured activities include story mapping, example mapping, and question storming. Nobody likes to be part of a soul-crushing meeting with no agenda and no tangible outcome.
Furthermore, the artifacts like stories, rules, and examples help teams do real planning instead of guessing. Estimates for size are much more accurate when they are based on actual rules and examples.
I feel like Discovery has an untapped market. Any time I have led these kinds of sessions, every participant finds them to be shockingly beneficial. Yet every time I teach others how to run these sessions on their own, they always get stuck. Now, I am usually not an expert in the domain of the stories we end up exploring, but I do have coaching skills to ask the right questions. The process works magic; I just need to do a little smoke in mirrors as a faux magician.
That’s what I think tools for activities like Example Mapping really need. You can build the most beautiful diagramming tools, but if folks don’t have guidance on how to use them, then they’re worthless. Now, with some social engineering and a little bit of AI, we could build a virtual coach into the tool to help teams complete the structured activities. The coach could ask the team probing questions to get them thinking. It could be a “scribe” for the team, rendering cards on the board and moving them around as a team’s exploration progresses. It could challenge the team when they are moving too slowly or becoming distracted by a tangent. Overall, the coach should help the team discover the product’s most important behaviors as efficiently and painlessly as possible.
Formulation
Formulation is the second phase of the behavior process. It is an activity of defining. In Formulation, teams write carefully-phrased specifications for the behaviors they explored during the Discovery phase.
Plain-language definitions with concrete examples are vital for good formulation. If a team cannot explain how a behavior works in plain language, then how could they ever expect a user to understand it? It’s much easier to explain behaviors with real-world examples.
Scenarios also need structure. Gherkin is the go-to language for BDD because its Given-When-Then steps follow the Arrange-Act-Assert pattern. Given the system is ready, When an actor performs an interaction, Then the system produces a desired outcome. This pattern frames one behavior individually and independently. Each scenario covers one behavior, which makes it easier to write, easier to understand, and easier to automate.
Gherkin syntax itself is fine for Formulation, but behavior tooling could be supercharged with a Formulation Copilot. In the same way that a Discovery Coach could help teams push through structured activities, a Formulation Copilot could provide advice and insights to team members as they are writing their behavior specifications. It should also be able to start by turning the artifacts generated by Discovery such as Example Mapping cards into “starter specs.”
Automation
Automation is the third phase of the behavior process. It is an activity of verifying. In Automation, teams automate their specs using test frameworks.
They should run their tests in Fast Feedback Loops like Continuous Integration pipelines to get value from their tests for every single code change. Remember, Continuous Integration is the production environment for test automation. If tests are not running in CI, then they are practically useless. Fast feedback enables teams to learn about the quality of the software and make informed business decisions about it.
When tests run continuously, their specs and their results become Living Documentation for the product. The results reveal the actual quality of the system as an active health monitor. The specs pinpoint where quality issues are happening.
Carrying out a cohesive process from inspiration to implementation also makes behaviors traceable. The specs act as a receipt or a proof-of-purchase for what the team “bought” with their planning. They hold the team accountable to delivering the behaviors that were intended.
There is so much that an intelligent Automation Watchdog could do for the Automation phase. If AI delivers on all its promises, a watchdog could just automate all the plain-language specs written during the previous phase. For example with web testing, it could either generate code in, say, Playwright, or it could just go into the web browser and enact the interactions based on its natural language understanding of the steps. Perhaps that’s too ambitious. More realistically, the watchdog could yield better analysis of test results and manage some of the triaging grindwork.
Furthermore, an Automation Watchdog could help us shift test automation away from “failure is bad.” For the longest time, we as testers have automated tests that perform interactions and assert verification. Interactions plus verification. That’s it; that’s testing. So, we hard-code the interactions, and we hard-code the verifications. Unfortunately, one of the most common problems with test automation is that any change in the behaviors under test will inevitably require tests to change as well, or else the tests will break and fail and send red X’s everywhere. Psychologically, it spreads bad vibes to say a test is “failing” or “broken” when the automation technically was successful in detecting a change. Perhaps an Automation Watchdog could become the ultimate change-detector and steer teams towards healthier perspectives about failures whenever they inevitably occur.
All Together
Discovery → Formulation → Automation. That is the full BDD process. I just outlined many ways we could reinvigorate these practices with better tooling. I want to top it off with one more idea: What if all this could be done within one app as one seamlessly integrated experience? One of the biggest pain points I’ve felt with BDD is the fact that feature files holding Gherkin scenarios can never truly be read and written by everyone on a team. Teams either stuff them into Jira for the product folks or commit them to Git repositories for developers and testers. There’s no possibility for a single source of truth because the tooling just is not there. It’s maddening. If we truly believe in these behavior-driven principles and practices, then as an industry and a community, we need to commit to them with better tooling.
I believe in these principles. I believe in these practices. I am thoroughly behavior-driven, and I do not believe I could approach software development any other way. It pains me to see how the BDD movement has stumbled when its tenets still have so much value to offer.
Time to Rebrand
Before I conclude, I want to propose one more big idea: I think it is time we rebrand BDD. I think it needs a new name. The current name has way too much baggage. Too many people hate it – or rather, they hate the terrible experiences they had under its impact. If we can be honest, “Behavior-Driven Development” just isn’t a good name anymore. Heck, anything that is “Something-Something-Driven Development” is a pretty lousy name.
I’ve thought to myself, what if we remove the word “driven”? Driving is for cars. We could shorten the name to “Behavior Development”. Still, that sounds clunky, and it doesn’t convey how folks need to focus more on the principles than the practices.
What I genuinely want folks to have is a Behavior Mindset when they approach software development. If folks actually put behaviors first and foremost in their mind, then everything else will fall into place. The specs, the code, and the practices all become artifacts of the process. We already have software development methodologies. Behavior orientation is really more of a mindset that complements existing paradigms.
So, enough with the three-letter acronyms. Enough with the baggage of the past. Let’s build software right. Let’s focus on the business value that matters.
We do Agile. We do DevOps. I think it’s time we also do Behavior.
Let’s build this future together!
[ad_2]
