I recently interviewed the creator of Cucumber, Aslak Hellesøy, about the ten year anniversary of BDD with Cucumber as well as BDD testing.
During our talk, he gave me one of the best summaries of why using just UI-based BDD testing is a bad idea.
Three Reasons Why UI-Based BDD Testing Can Stink
Aslak outlined three ways in which UI-based BDD using tools like Selenium can cause issues. They are due to UI tests, in general, being:
- Slow
- Brittle
- Hard To Maintain
The Most Common BDD Mistake
One of the most common mistakes Aslak and myself see is when people write Cucumber scenarios in the same way that one would write a manual test script.
A manual test very often involves opening up a web page, navigating to a certain page, filling in some fields, and either clicking some buttons or looking at the screen to see what's there.
All these things can be done with Cucumber combined with a tool like Selenium.
Why this BDD Approach is Bad
But it just so happens that if that's what you are doing, you are writing the slowest possible tests possible. They're also the most brittle tests you can possibly write, as well as the most difficult to diagnose.
Why UI-Based BDD is Slow
UI-based BDD tests are slow because they go through all of the layers of your stack with lots of networking.
Why UI-Based BDD is Brittle
UI-based BDD testing tends to be brittle because your user interface keeps changing; it’s typically the part of the application that changes more often than the actual logic underneath.
Why UI-Based BDD is Hard to Debug
Lastly, UI-based BDDs are hard to diagnose when they fail because the problem could literally be anywhere in your system if you don't get a good stack trace when something doesn't work properly.
A Better BDD Testing Approach for Faster Tests
The conventional wisdom to address this problem is to try and write your scenarios in such a way that you don’t talk about the user interface.
Instead, you talk about what the user intends to do.
For example, imagine that want to transfer some money from your checking account to your savings account.
One way to write that scenario is to say that I open up my bank’s website, click on my checking account, enter the amount to be transferred into the box and submit the update account button, which means the balance label should be this value.
But you can write this in a much more terse way.
For example, if I have a hundred dollars in my checking account and a hundred dollars in my savings account, when I transfer $20 from the checking to savings I should then have $80 in checking and $120 in savings.
So you're talking more in terms of all of the business processes rather than just the user interface.
Writing BDD Test for Business Logic is not UI-Specific
This approach has some great benefits. Now that you're not tied to the user interface, you can choose which stack level of your application you want to connect your test to.
You can still connect to the UI if you wish, but you can also– with a little bit of programming–connect them to the lower- level domain logic that sits behind the UI and even behind the web server and test the same logic for exceptionally fast feedback.
Writing BDD for Readability by All Team Members
Another benefit you get from this is that you’ll know you're documenting the business process instead of documenting the UI, so you're much more likely to be able to show a Cucumber scenario to somebody from the business and get some valuable feedback on it.
That's actually been a problem for many teams; they have reams and reams of Given, When, Then and it's so detailed that when you give it to somebody who just wants to make sure you're doing the right thing, they can't follow it and don't particularly want to see it.
How to Make Really Fast Cucumber Scenarios
By now might be saying to yourself, “This makes sense, but give me an actionable way that can actually help me make my Cucumber scenarios faster.”
No worries.
If you Google todo-subsecond you’ll find a small To-Do list application that uses Cucumber as well as some design patterns that will help for make your end-to-end tests run in milliseconds.
This example uses a tiny web app to demonstrate sub-second full-stack acceptance tests with Node.js and Cucumber, but the principles apply to any programming language you might be using for your Cucumber BDD projects.
Breaking down this example is a great way to learn about more efficient Cucumber BDD design patterns for your tests.
To discover other ways to help improve your test automation efforts make sure to check out the Automation Guild Conference and Community!
You can still get the recordings for 2017 Automation Guild conference that had sessions from Seb Rose on An introduction to Cucumber and Matt Wynne on Keeping your Cucumbers sweet.
