Hey Kids, keep away from cucumbers
My message to future generations of test automation adepts.
Cucumber, and generally speaking BDD, is gaining in popularity and becomes an attractive CV’s feature for people who test. I would, however, advise against taking Cucumber as one of the first choices for testers who aren’t so experienced in test automation yet. Especially if in the organization that you’re working for doesn’t exist a culture of Behavior Driven Development (BDD).
Before I started I want to make the things clear: Cucumber is a very powerful tool and I strongly believe living documentation is worth the candle but there’s no rose without a thorn.
My story
I started working in a company that was at the beginning of its development road. I joined as a very first QA Engineer without much experience, but with huge ambitions to learn and do my job well. At that time I had a free hand in choosing a technology for test automation purposes. After a lot of tries and failures, I decided to go with Jenkins and Cucumber. Today, when I’m thinking about the choice I’ve made, I don’t consider it a big mistake. Because it wasn’t. There are plenty of factories saying pro-Cucumber especially in case of the project that I was working on. Briefly speaking, it’s a web app being a long-form where steps are always one after another and user journey ends always at the very last page. Cucumber provides very powerful tools like reusable steps or scenario outline that, at it may seem, fits perfectly to this particular kind of product. But at that time I didn’t know what I know now.
I wasn’t aware that an entry-level to Cucumber is quite high compared to “regular” test runners like mocha or Jest. Writing scenarios in a domain-specific language like Gherkin isn’t so easy especially when you want to do it right and when you only read a few articles on the Internet and watched a single tutorial on youtube. It’s a challenge that you must take up at the beginning what is a really big load.
In the time when a newbie tester should focus on learning how to automate, solve typical test automation issues, he must figure out how to fit the requirements into Gherkin-like scenarios.
It’s time-wasting on this stage. People who start automating, especially through UI, should keep things simple. Otherwise, the deadline for delivering test automation solution won’t be met.
Cucumber and Gherkin bring more challenges, the architecture ones. Reusing steps sounds like a grail, but it requires damn good skills of designing the code. Let me give you an example: the frontend that you’re working on is being developed in a modern framework. It’s been developed in SPA way, has very fancy animations and generally speaking it’s good as hell. What probably it does mean for a tester? Big troubles. How to smartly handle page transitions? How to wait for animations to be done? Eventually, where to put an ugly pause() if there’s no other way? Should I put it to step definition? What if we must handle the same issue in multiple step definitions differently because we have both very generic steps and more specific ones? Okay, so if it’s not a good idea, let’s put it to the method that does the action. But hold on! methods should be predictable and kept straightforward, is it for sure a good place for our pause()?
Another example of coding hurdles to reach is dealing with the cool Cucumber’s features like a data table, scenarios outlines. Every of those functionality gives you a powerful tool but also brings more, and more places to make a potential mistake that could cost you big. Let me explain what I mean.
It might be a good idea to use data table to list down all values that we want to put on the particular page. Let’s say you’d like to test a feature that requires filling out two or even three forms. What do we receive in the result? Quite unreadable, or at least not best practices friendly, scenarios, that prevents you to use scenario outline to reuse the scenarios for different inputs.
For many of you who are more experienced in Cucumber might seem the given examples very abstractive and totally against the way how this framework should be used. And I agree. But they are the real examples from my life story. Thus this post. I want to warn people to double consider to run into Cucumber at the early stage of their career as a tester. I’m not saying it’s not a bad tool, I’m just saying it’s rough terrain.
Post scriptum: I’d like to recommend for anyone who is interesting to give a chance to Cucumber to read a book The Cucumber Book: Behaviour-Driven Development. It opened my eyes, I wasn’t aware of many cool features that the tool has. Honestly speaking, online documentation could be much better.
