A Practical Advice on Rejecting Gherkin for Test Automation

Prevent this recipe for failures in E2E test automation; Prevent embarrassment.

Gherkin BDD frameworks (such as Cucumber, SpecFlow, JBehave, Concordian and Gauge) are often used in test automation, which is wrong!

The fact: few engineers have seen, let alone implemented, a successful Automated E2E regression testing. Check out the AgileWay Continuous Testing Grading.

Gherkin is a wrong choice for Test Automation

Don’t just take my word for it. Have a look at the following quotes from Aslak Hellesøy, the creator of Cucumber.

“Using UI testing tools together with Cucumber? Please don’t — or at least do it very sparingly.” (link)

“If all you need is a testing tool for driving a mouse and a keyboard, don’t use Cucumber. ” (link)

For more, check out my articles:

• BDD Clarified: BDD ≠ “Given-When-Then” (Gherkin)
• Why Gherkin (Cucumber, SpecFlow,…) Always Failed with UI Test Automation?

How to avoid using Gherkin in your project?

Frankly, if management and architects have already decided to adopt Gherkin for BDD test automation, it is almost impossible to change their minds. This is how office-politics works, don’t waste your time debating. But if the management asked you for opinions, and you know “Cucumber/SpecFlow/JBehave” is a road to failure, how can you convince others?

First of all, it is not easy. Because some already were hyped about using BA-written (Given-When-Then) requirements for automated tests. During my contracting/consulting (over 10 years), I failed to change their mind. I used the expression such as “Most test automation with Cucumber failed”, I even borrowed the quotes from the absolute authority such as Cucumber’s creator and DHH, but still no use. Someone would say: “It worked very well in my last project, …”. Confrontation seemed inevitable.

I changed tactics at one company, and with some degrees of success. Background information: all previous test automation attempts have failed for this large…