Test Automation: Why You Should Use Cucumber?
I’ve been using Cucumber for over 10 years now and through my work as a Freelance SDET it never ceases to amaze me to find how many places have not implemented it very well! This is not just from a collaborative point of view which was the tools original intent but from a technical point of view also.
HISTORY
Cucumber was introduced in 2010 as RSpec. Originally implemented in Ruby and then Java it is now available as a library for most programming languages. Cucumber together with the Gherkin syntax is a way of describing the behaviour of an app or system and Behaviour Driven Development(BDD). BDD extends the principles of Test Driven Development (TDD) by emphasising collaboration and communication between different stakeholders involved in the software development process, such as developers, testers, product owners, and business analysts. BDD focuses on writing tests in a more human-readable language that can be understood by both technical and non-technical team members. Cucumber has developed into the main tool for doing this.
IMPERATIVE/DECLARATIVE — Who cares?
A lot of people get hung up on the Imperative/Declarative debate but I think they are missing the wood for the trees. Imperative style describes the exact steps taken to describe a test scenario and Declarative is a more high level approach.
DECLARATIVE
Scenario: User successfully logs in
Given a registered user
When they log in using valid credentials
Then they should access the dashboard
In my opinion the choice between imperative and declarative styles often comes down to a matter of preference, team conventions, and the level of detail required for your testing process. If you find your step too imperative you can easily wrap your low level steps into something more abstract.
IMPERATIVE
Scenario: User logs in with valid credentials
Given the user is on the login page
When the user enters their valid username
And the user enters their valid password
And the user clicks the login button
Then the user should be redirected to the dashboard page
And the dashboard should display the user’s name
What is often overlooked though is the fact that Cucumber is great for adhering to DRY (Don’t Repeat Yourself) principles of code reuse. The step definitions can be parameterised and reused for different scenarios.
IMPERATIVE WITH CODE REUSE
Scenario: User logs in with valid credentials
Given the user is on the “login” page
When the user enters “jdoe@me,com” in “Username textfield”
And the user enters “Password123” in “Password textfield”
And the user clicks the “Login button” element
Then the user should see “Welcome John” in the “Dashboard title” element
Where the speech marks are used we can parameterise our step definitions and we can reuse the code.
TECHNICAL BENEFITS
The main technical benefits are:
- Code Reuse: This means less code to write making it more extendable and maintainable.
- Test Automation Estimates: If the step defs are being reused then that is work we don’t have to do so its easier to estimate and plan QA time
- Test Data — Cucumber can display the data within the tests themselves and Scenario Outline tables can be used to describe different permutations of the same scenario
BUSINESS BENEFITS
Last but not least Cucumber/Gherkin is a great collaboration tool:
1. Domain Expertise: Its a great way of conducting walkthroughs with domain experts (BA’s etc)
2. Test Case Creation — Coming up with novel but impactful edge cases is easier because the whole team can understand the tests
3. Documentation — The Cucumber tests are essentially documenting how the system/app behaves. This is great for onboarding new team members but also to any outside stakeholders who want to grasp the essence of the system
During the initial stages of Cucumber implementation, it’s understandable to perceive the collaborative advantages as relatively less valuable in contrast to the upfront time and cost required for setting up an additional technical layer. This initial skepticism can sometimes lead to placing blame on Cucumber for any subsequent failures. However, it’s crucial to recognise that the true root cause often lies in the lack of experience in implementing optimal Cucumber practices, which can ultimately undermine automation endeavours.
In conclusion, Gherkin/Cucumber, when integrated alongside sound UI, API, and database automation principles, emerges as the cornerstone of a robust automation framework. While its adoption may entail initial investments in time and resources, the dividends it pays over the course of a project’s evolution are undeniable. The seemingly time-consuming effort of establishing an additional abstraction layer is overshadowed by the remarkable value it brings to the project.
