There is a great deal of debate concerning the adoption of Cucumber for Test Automation Framework. Some love the simplicity and understandability of Cucumber’s natural (English!) language syntax, while others complain that it’s just another tool to learn that doesn’t scale to support the automation of really complex scenarios.
Both points are valid to some extent, and so, the big question is: Is Cucumber based Test Automation worth the effort? The short answer (in our humble opinion): Yes.
Reasons to adopt Cucumber for Test Automation
The important aspect of Cucumber is that it uses plain-text (Gherkin Language) to communicate tests in non-technical terms. This alone is invaluable because it allows for the intent of the test to be expressed outside of code, meaning that it can be understood by everyone involved in the Software Development Lifecycle.
We see this first hand in large, geographically & functionally distributed enterprise teams. Presenting automated test coverage, and the corresponding results, in Cucumber brings all stakeholders (Business, Engineering and QA) on the same page and offers a common understanding of automation coverage with corresponding quality (and issues).
For example, many Awetest customers are actively using Ruby and Cucumber to build their automated tests. Our Customer teams are collectively running over 200,000+ cucumber based tests per month and that number is increasing rapidly! We’ve found that using Cucumber brings a lot of advantages to our enterprise testing efforts for the following reasons:
With Cucumber, test cases can be understood by all key stakeholders.A key challenge with automation developed using traditional automation tools is that the final output is code in a variety of different languages (VBScript for QTP/Mercury, Java/ Ruby/Python for Selenium, etc.), which makes it virtually impossible for the typical non-technical business user to follow. Cucumber, on the other hand, levels the playing field & virtually eliminates any ambiguity regarding the test case and corresponding coverage.
The revolving door in today’s IT environment renders many QA teams’ automation assets worthless when the author leaves. Additionally, incremental updates to traditional (VBScript, Java) automation tests typically result in complicated blobs of incomprehensible code over time. Again, Cucumber’s readability makes it very transferable and easy for new team members to maintain and expand the existing test case as needed. This is a big bonus for an organization.
Cucumber tests are easy to adopt agile, they can actually be developed during the sprint planning stage unlike test cases developed in other languages. If the enterprise wants to adopt agile methodologies to properly conduct enterprise testing, they need to eliminate roadblocks, and sluggishness is a key roadblock. We have found that when we work with our clients they are constantly dealing with incumbent processes that are hard to change.
The Gherkin language has a natural separation of test case steps with underlying implementation. This creates a tendency to develop a library of reusable test case steps.
From a recent project automating tests for a Responsive Application, our team was able to successfully reuse an entire library of custom Cucumber steps that were originally built to support our mobile (phone & tablet) test automation . More importantly, the folks building the mobile automation scripts (using the existing libraries) could do it with almost never touching the underlying Ruby Code in the library.
Cucumber can be used across all target platforms and as a wrapper around multiple technologies. All major Open Source automation engines (Selenium, Watir WebDriver, Calabash, Appium, Frank, etc.) support Cucumber. We’ve successfully implemented Cucumber based automation for our customers across all of our modules – Cross-Browser (Web), Mobile iOS & Android Browsers (mWeb) and Native & Hybrid iOS & Android Apps (mApp).
Overall, Cucumber is easy to adopt for enterprise testing and the potential return on investment is large enough to warrant its inclusion within the SDLC. Check out Cucumber 101 for information on the basics and architecture of Cucumber, along with how we leverage it for our automated tests.