3 myths about Cucumber and Gherkin
Cucumber is a Behavior-Driven Development style software tool. If you’re not familiar with it, here are its main advantages.
Kamil Nicieja
Unified Payroll is fully launched!
Read Story →
Checklist: How to Evaluate a Potential Payroll Provider
Read Story →
Pilot is now Plane!
Read Story →Cucumber scenarios can be read by anyone on your team. And because they can be read by anyone, you can use them to help improve communication, collaboration and trust on your team. 💪Here’s an example:``` Given a bus with a number 144 that’s nearby the Main Street stop And a bus with a number 122 which is 5 minutes behind When 144 approaches the Main Street bus stop Then the text displayed on the indicator board for 144 should change from “1 minute away” to “please enter” But the text displayed for 122 should be “5 minutes away”```Personally, I love using Cucumber—and it hurts me to see that it’s often so fundamentally misunderstood. Let me explain why.
Myth 1: Cucumber is a testing framework.
Cucumber does run automated acceptance tests, but it certainly isn’t just a testing framework.I think this misconception originates from a systematic failure to understand what BDD and its ancestor TDD really are. Both processes are test-first design methodologies—but they’re not testing techniques. The objective of testing is to find bugs. The objective of design is to produce a blueprint of code that needs to work.Kent Beck, the creator of Extreme Programming, a methodology that helped TDD hit mainstream, described TDD’s approach as “code a little, test a little” to write “clean code that works.” In this light, a test is simply a byproduct of TDD’s engineering process; the real goal is well-designed code.What’s the truth?
Since BDD and TDD share many underlying concepts, Cucumber doesn’t consider tests to be its main artefact, either. It purposely defines itself as a collaboration tool, not a testing framework.Cucumber facilitates BDD’s process in a holistic, cohesive way that lets software engineers capture requirements using Gherkin’s syntax, then easily turn Gherkin into the system documentation, then execute that documentation with automated acceptance tests to ensure it stays up to date. All parts are equally important.Myth 2. Cucumber equals end-to-end Capybara.
Inside the world of Ruby on Rails, Cucumber is typically associated with using Capybara for an end-to-end system testing. It’s a fundamentally limiting approach to harnessing benefits of a business-readable DSL like Gherkin.What’s the truth?
End-to-end UI testing definitely isn’t the only way to use Cucumber. Since BDD is a test-first approach just like TDD, you can use Cucumber for unit testing, too, to create code that reflects a full-blown model of your business domain filled with meaningful real world examples and written in ubiquitous language.Those familiar with a Domain-Driven Design approach and benefits will recognize the significance of Cucumber’s focus on the ubiquitous language. It aims to eliminate the cost of mental translation between domain experts and software engineers with their technical vocabulary, thus reducing the number of misunderstandings in discussions between technical and non-technical stakeholders.Eric Evans, the author who coined the DDD term in his book of the same title, stresses how important it is to design code using the ubiquitous language to build valuable software without rework and domain misunderstandings.End-to-end testing with Cucumber wastes the benefits of Gherkin’s business-friendly style, because the the ubiquitous language built in scenarios doesn’t have a direct relationship with code. Domain-oriented unit tests will easily let you inject the business domain model into your code—which will improve the design.Myth 3. Cucumber tests should maximize code coverage.
Hear the truth and let it free you: you don’t have to test everything. Testing every possible use case is a job for QA engineers. But they use different tools to do that—or they use the same tools, but they do it very differently.What’s the truth?
Spec examples serve another purpose. Since Cucumber is a communication tool, the examples should improve reader’s understanding of what the described feature is about.There’s no need to employ every possible test heuristic to cover every possible use case. Find the very essentials and describe key examples. You don’t even have to test every class in the system. If a class isn’t related to the business domain and doesn’t bring visible value to non-technical folks, it really shouldn’t be described in Gherkin. That’s noise in the signal.Many practitioners admit that they were discouraged from using test-first design due to some of TDD’s engineering dogmas. I think Cucumber’s emphasis on non-technical stakeholders helps reduce the over-engineering of your testing stack.---When I say Cucumber and Gherkin improve code design, I don’t want you to think about an overly complex web of intermediary objects built in order to avoid doing anything slow. I want you to think about getting to know your business domain better to avoid future reworks and bugs. Business-focused Cucumber tests encourage such thinking. 👌Further reading
Cucumber is not a testing framework!Test-First DesignIntroducing Modeling by ExampleRelated articles
From startups to large corporations, US companies of all sizes use Pilot for international payroll, benefits and compliance.
Introducing Plane’s Accounting Automation
Speed up your month-end close with our new accounting automation.
