Introduction to Cucumber Tool

Profile picture for user devraj

Cucumber is an Open Source test automation tool that supports Behavior Driven Development (BDD), and it is used to write acceptance tests for different applications. 

Aslak Hellesøy created Cucumber in 2008. Other developers are Joseph Wilk, Matt Wynne, Gregory Hnatiuk, and Mike Sassak.

Cucumber was originally written in Ruby Language. It was exclusively used only to test Ruby as a complement to the RSpec BDD framework.

These lines from the book The Cucumber for Java Book (Behaviour-Driven Development for Testers and Developers) by Seb Rose, Matt Wynne & Aslak Hellesøy will absolutely explain why you need Cucumber: "Companies often have huge issues with trust - the customer doesn't trust the supplier, the business doesn't trust the developers, the developers don't trust the testers, and the testers don't trust anyone. Cucumber gives the business, developers, and testers a way to collaborate and specify, in plain English, how the system should work."

Why Cucumber?

  1. Multiple Language Support: It supports almost all popular languages like Java, .net, JavaScript, Ruby, PHP, Python, etc. 
  2. Code Reusability: Due to simple test script architecture, Hooks, Background, and Data Table, Cucumber provides code reusability. Also, Exact Gherkin Steps we can use in other test scenarios. 
  3. Easy to Understand: The test case writing is straightforward and understandable. It works as a bridge between business and technical language, and this bridge is sustainable because of test cases written in plain English text. It uses Simple grammar defined by a language called Gherkin. Even your manual testers can write test scenarios. Actually, Not just a Manual tester; even BA and other stakeholders can write stories in Gherkin Language.
  4. Acceptance Testing Tool:  It bridges the gap between business people and developers. It is more than a test automation tool; it's a collaboration tool, or you can say It is an acceptance testing tool. Cucumber enables the direct automation of the specification, which means that anyone can see, at a glance, what functionality has been implemented and what hasn't. 
  5. Less Documentation: You can save a lot of documentation time when your Business Analyst writes your stories in the Gherkin language. Your manual tester also writes in test cases in Cucumber-friendly language and the same scenarios you use for automation.