.webp)
Behavior-Driven Development (BDD) is not a new idea. There are still recordings available online showing presentations on the topic given as early as 2009! Still, many people are tip-toeing around the concept, asking themselves questions like:
- Is BDD just Yet Another Hype, or is there something substantial?
- Is it relevant to my own work?
- Why should I consider a behavior-driven approach to test development?
The answer to all three questions is a clear and resounding 'Yes!'. A behavior-driven approach to GUI test automation using Squish brings major benefits, spanning from being able to test earlier and involving more people in the process, over concrete advantages in implementation such as better modularization and tooling support all the way to more sophisticated ways for test result analysis.
Let's elaborate on each of these benefits and see what they are about:
- More Robust Tests Through Abstraction: What, Not How
- Improved Collaboration: Speaking A Common Language
- QA From The Get Go: Testing Software Which Does Not Exist
- Better Tooling Support
- Zero-Cost Best Practices: Automatic Modularization
- Simplified Result Analysis: Semantic Test Reports
However, let's first make sure that we're all on the same page regarding what BDD actually is.
A Quick Refresher: What Is Behavior-Driven Development?
Behavior-Driven Development is an approach to software engineering which encourages collaboration between different roles in a software project, such as software developers, test engineers or non-technical team members. A central idea is to encourage conversation and use examples to create a common understanding between all team members of how the software should work.
This is largely facilitated through the use of a simple domain-specific language using natural language constructs (e.g., English-like sentences) that can express the behavior and the expected outcomes. The Gherkin language is a quasi-standard for expressing the desired behavior. Functionality of the software is described in terms of features ("Create A Preview Rendering"). Each feature is then described in different use cases ("scenarios") such as "Creating a preview rendering of a green cube". Finally, each scenario is expressed as a sequence of interaction steps, typically grouped in a 'Given/When/Then' structure.
Although BDD is principally an idea about how software development should be managed by both business interests and technical insight, the practice of BDD does assume the use of specialized software tools to support the development process. Squish features first-class support for behavior-driven GUI test automation projects.
See the website bdd.tips, to learn more about how to do Behavior-Driven GUI test automation with Squish!
1. More Robust Tests Through Abstraction: What, Not How
A critical requirement for automated tests is that they are stable. This means that they should continue running even if the AUT under test changes. A lot of work has been put into Squish to make sure this is the case. As it happens, most of these measures implement a central, fundamental insight: test code should be as abstract as possible.
This means that instead of describing a test in terms of how something is done (e.g. by clicking on a certain button or, even worse, clicking on X/Y coordinates on the screen), focus on what is done - e.g. Confirming Account Creation.
Working in a powerful scripting language makes it all too easy to get the level of abstraction wrong though: it requires a lot of discipline to stay focused on the what.
The Gherkin language used for expressing behavior-driven tests encourages good practices: it lacks typical scripting language features such as loops or conditional expressions. It also imposes a minimum of syntax and thus, for the most part, reads like plain text. This greatly helps with keeping a good level of abstraction.
2. Improved Collaboration: Speaking A Common Language
Software development is a team sport: except for the simplest projects, most software is developed by a group of people. In many cases, different people assume different roles in the process, such as:
- business analysts gather an understanding on what the customer needs
- interaction design experts model an appropriate user interface
- software developers implement the application
- quality assurance experts measure the quality of the product
A behavior-driven specification using the Gherkin language is a great way to make sure that everyone is on the same page. If written correctly, they can be of create use right from the start of the project. Customers can review them for plausibility, interaction design gets a clear understanding of the desired use cases and test engineers, when given a software tool which supports the Gherkin language, can use them as readymade test cases which software developers can work against.
A behavior-driven test case thus acts as an executable specification which conveys the same information to entirely different roles. It acts as a single source of truth and avoids misunderstandings caused by passing information from one team member to the other.
3. QA From The Get Go: Testing Software Which Does Not Exist
A major advantage of the BDD support in Squish is that it permits running Gherkin descriptions of the desired behavior even without any application at hand!
When creating BDD test cases in Squish by loading a Gherkin description, the Squish IDE initially displays warning icons next to all steps:
This indicates that the test cannot be executed as it is: the tool needs to know which UI interactions to execute for every step. However, it is possible to have Squish generate 'Step Implementation Skeletons' which are empty functions associated with each of the steps. With a single click, all steps will be associated with an empty (no action) implementation:
Once all steps have been implemented (even if the implementations are just empty skeletons), you can start executing the tests: they all pass, but emit a warning - reminding you that this step still needs to be implemented. Since the tests can be executed, you can integrate the test suite into your continuous integration system and make sure that they are executed.
As the application is implemented and features are added, you can then go ahead and implement the empty placeholders. That way, your test suite grows in parallel to the application - development and testing goes hand in hand.
4. Better Tooling Support
The Squish IDE understands that there is a structure to Gherkin documents. There are features, and scenarios, and steps which are typically given in a 'Given/When/Then' structure. By taking advantage of this, the IDE can provide better support for test development than it can for plain script-based test cases. The power of script-based tests is that they are free form - but that means that the IDE can make less assumptions.
One example for the improved tooling support is auto-completion: when writing a plain script-based test case, Squish helpfully auto-completes function names. However, since you can invoke any function name at any point, the completion can be rather large and require some navigation until you find just the right name:
The completion is much more accurate for BDD test cases: the IDE knows that after a 'Given' step, you most certainly don't want a 'Then' step. Thus, it can optimize the list of suggestions such that you are more likely to find relevant relevant matches right at the top of the list of suggestions:
It get's better though: another compelling benefit of BDD tests is that they help with recording new tests!
When working with traditional script-based tests, recording new script code is either a matter of
- recording a new test case from scratch, possibly repeating common interaction sequences such as logging in over and over again
- recording a script snippet, which requires very carefully identifying the exact position at which the recorded sequences of interactions should be inserted into the script code
Behavior-driven test cases greatly improve on this. When recording a BDD test case, Squish will replay those steps for which an implementation is available, suspending the recording only for those steps which are not known yet. You can then gradually fill in all the missing steps in a single session while also making sure that existing step implementations (which may include custom modifications!) are automatically reused.
See this video for how recording BDD test cases works in practice:
5. Zero-Cost Best Practices: Automatic Modularization
There's another benefit related to the implementation of behavior-driven GUI tests which becomes apparent only on second glance: automatic modularization.
Traditional script-based test cases require a lot of careful consideration and discipline to avoid that they grow into huge monoliths of script code which are hard to maintain, extend or reuse. It's very easy to accumulate technical dept, and avoiding this problem requires employing professional software engineering practices.
Behavior-driven GUI test development helps a lot with this. Instead of working with one contiguous block of script code, a Gherkin document implicitly decomposes a complex test procedure into smaller steps. Equally important: each step is defined by its semantics. Instead of describing how something is done ("Click the Create button"), a step explains what is done ("Create the user account").
This automatically provides the right level of abstraction: much like a seasoned software engineer would have done, the script code is nicely decomposed into individual functions, each of which being "named" (via the step text) based on what the function should do and the implementation defining how it is done.
6. Simplified Result Analysis: Semantic Test Reports
Gherkin documents are executable documentation. They accompany the entire project development process, and the test reports are no exception. By associating the original Gherkin description of the desired behavior with the final test report, each verification is associated with the step which was executed at the time the verification was done. This means that in addition to documenting how something was verified ("Expected button to be enabled, but it's not"), the test report also documents what was verified ("It should be possible to save the document").
Furthermore, the structure of the BDD specification is retained. Each BDD test case is structured hierarchically, with a feature being tested at the topmost level and different scenarios in which the feature is exercised as the second level. Thus, when browsing test reports, you don't have to face a huge sequential list of verifications but instead can gradually drill down, viewing the test reports on different levels of granularity.
This becomes especially apparent with powerful test result management platforms like Test Center. The structure of a Gherkin document is nicely visible, letting you drill down very nicely while focusing on what was done, not how:
All right, I'm Sold
Did we manage to whet your appetite? Want to explore the merits of behaviour-driven GUI test automation futher? Great! Here are some excellent resources:
- If you haven't done so already, check out Squish, a GUI test automation tool with first-class support for BDD.
- While tinkering with Squish, have a look at the website bdd.tips for a great overview of many useful Gherkin features.
- For managing and reviewing test reports generated by Squish, have a look at Test Center.
Enjoy!
