Behavior-driven development. Who needs Gherkin?
Behavior-driven development is a popular agile methodology. Here, we discuss how to do BDD without the need to learn the Gherkin language.
Behavior-driven development is a popular agile methodology that can achieve good results. However, many people assume that BDD is only possible if you use Gherkin. Here, we discuss why this is, and show that there is an alternative.
Introduction
Behavior-driven development is attracting a lot of attention recently. BDD focuses on the needs of the end-user, focusing on how the software behaves, not whether it passes the tests. However, BDD has become inextricably linked with its language, Gherkin. But what if there was an alternative language? What if you could just create tests directly from your user stories? Here, we explain how this is possible and show why this is a much better approach for true behavior-driven development.
Behavior-driven development was invented well over a decade ago. Back then, a lot of teams were starting to adopt test-driven development. However, as is common when you get a lot of smart techy people together, these teams were starting to lose sight of the actual aim. Passing the test began to take precedence over producing good software. In a 2006 blog, Dan North explained the origins of BDD.
Behaviour-driven development started life as an NLP exercise to stem the abuse of the word “test” in “test-driven development”.
Nowadays, everyone assumes NLP means natural language processing. However, back in 2006, the acronym stood for neuro-linguistic programming. So, what Dan North was trying to do was shift the focus of TDD from passing tests to achieving correct behavior.
BDD focuses on defining requirements based on the desired behavior of your software. These requirements can then be converted into code. Finally, you can use the same requirements to check for the correct behavior of your program. The problem was, how could you capture requirements in such a way that a computer could understand them? When BDD was invented, the only way to do something like this was to create a domain-specific language. The result was Gherkin, a formal language for capturing software requirements.
Gherkin overview
Gherkin is a formal language for describing software features and test scenarios. It makes use of a set of keywords. The best known of these are the Given/When/Then triplet that is used to describe each test scenario. The problem is because Gherkin is so formal, it makes writing features and scenarios quite hard. For instance, the following is a simple scenario for a login button.
The user story for the login flow might look like this. “As a user, I want to be able to log in to the application. If I forget my password, I want to be able to request a password reset.” Now let’s see how that looks as a Gherkin feature.
Feature: Log-in buttonA user should be able to log in to the application by entering their credentials and clicking on a button. Provided the user enters a valid username and password, the button should log them in and take them to their homepage.
Scenario: User enters valid credentials
Given the user is on a page with the login form
And the user has entered the username “testing1”
And the user has entered the password “Password123”
When he clicks login
Then the user is taken to his homepage
Scenario: User forgets their password
Given the user is on a page with the login fields
And the user has entered the username “testing1”
When he clicks the “Forgot password” link
Then the user is taken to the reset password page
Scenario: User enters invalid credentials
Given the user is on a page with the login fields
And the user has entered the username “testing1”
And the user has entered the password “Password321”
When he clicks the login button
Then the login form is displayed again with the username still populated
While this is comprehensible, it isn’t easy to read or write. The problem is, writing in such a formal fashion is really hard. And if you get it wrong, you end up missing some essential aspect of the test.
The present state of BDD
Move the clock forward almost 15 years, and behavior-driven development is getting more and more attention. There’s no doubt that BDD helps to ensure you produce software that actually works as it should. The real issue is how to combine BDD with automated testing. There are many classic approaches to this. Cucumber is probably the best-known test framework for BDD. But there are other tools like Specflow for .net or jbehave for Java. However, these tools require significant effort before you can actually create automated tests. Moreover, they are all predicated on you creating features and scenarios in Gherkin.
The problem is, there is such a strong link that many people mistakenly think BDD == Gherkin. However, BDD was always intended to be more of a methodology for improving agile development. Behavior-driven development doesn’t require you to write in Gherkin, it’s just that Gherkin is the usual approach to implement BDD.
What’s wrong with English?
In the intervening years since BDD first emerged, natural language processing has advanced beyond all recognition. Nowadays, everyone is used to asking “Alexa, what’s the weather today?” or “Siri, read me my messages.” So, if a computer can now understand human language, why do we need to learn a special language to get a computer to create tests for us? Why do we need to learn the computer’s language when the computer can learn English? This is the fundamental philosophy behind our Natural Language Processing engine.
NLP in brief
Functionize is an intelligent test agent that makes it easy to create, execute, and analyze automated tests. NLP lies at the heart of our test creation approach. Put simply, it takes your test plans written in plain English and uses them to create fully-functional tests. It does this using a combination of machine learning, NLP, and computer vision. The resulting tests are able to run in any browser on any platform. The power of NLP is that you can pass it both unstructured and structured test plans. Structured plans are what your test management system generally produces. Unstructured plans could be descriptions of user journeys or even free text just describing the test.
Combining NLP with Behavior-Driven Development
So, given NLP allows you to write tests in plain English, how can you combine this with BDD? How can you adopt business-driven development without the need to teach everyone Gherkin? In short, how can you democratize BDD? Well, let’s go back to the fundamentals. BDD is about focussing your efforts on code that achieves certain required behaviors. Gherkin offers one way to describe those behaviors, but your product team already has a whole host of other ways.
BDD without Gherkin
The important things are:
- Define your requirements in terms of the expected outcome. This can be done by thinking in terms of features and desired behaviors. Your product team does this all the time. So, rather than get them to convert the features into an exhaustive list of requirements, get them to give a list of behaviors. These can be written in any format, as long as your developers understand them.
- Write your code so that it achieves the defined behavior. By avoiding a list of requirements, you are freeing up your developers to work more efficiently. Chasing requirements can often get in the way of achieving results. And it is fundamentally not agile.
- Come up with the set of tests that check for the correct behavior. With NLP, this becomes really simple. You just need to write down the tests that you want to be performed. The complexity here comes from the need to check all happy and sad paths. But by definition, the happy paths are defined as ones that achieve the required behavior.
- Check your code can pass the tests. With the Functionize test cloud, this is a really simple step. You can run hundreds of tests in parallel across multiple browsers. Analyzing the results is simple too since we have adopted a visual testing approach that uses screenshots to highlight unexpected outcomes.
- Refine your code so that it becomes performant. This last step involves refactoring your code and making it production-ready. Of course, part of this is to verify that all the tests still pass. You might also use our load and stress testing engine to check the performance under realistic loads.
The above steps let you achieve all the requirements of BDD without the need to use any formal languages.
Conclusions
BDD is a really powerful methodology if you are trying to do agile development effectively. But as we showed, you can achieve BDD without the need to use the structured Gherkin language. Instead, Functionize NLP lets you use English. As a result, we have made BDD accessible to every team without the need to learn any new domain-specific language.
