Why No Cucumber BDD for Test Automation?
Images created by Google Gemini at https://gemini.google.com/

Why No Cucumber BDD for Test Automation?

The best part about using Cucumber is that automated tests are written in plain English. ?This makes it easy for everyone, not just programmers and technical testers, to understand what is being tested.

Since all BDD automated tests are written as behavior scenarios, they also serve as living documentations. System stakeholders can review whether acceptance criteria is being met by referring to the Cucumber test results.


Black-Box vs White-Box Testing:?

Cucumber promotes a black-box approach, focusing on user-facing behavior without accessing application internals.?

On the other hand, test automation tools such as Cypress and Playwright excel at white-box testing, allowing manipulation of application state, network, and internals – functionalities limited by Cucumber's black-box nature.


The argument against using Cucumber BDD on top of Cypress and Playwright is that it hinders the advantages of these frameworks.


  1. Readability and Maintenance: Cypress and Playwright commands are inherently clear. While Cucumber's Gherkin syntax can be readable, maintaining complex scenarios with changing application behavior can be challenging compared to Cypress' straightforward approach.
  2. Reduced Effectiveness:? Cucumber's Gherkin syntax promotes a "black-box" testing approach, which doesn't leverage Cypress and Playwright's ability to access application internals and manipulate its state. This makes tests less efficient and powerful.
  3. Maintenance Overhead: ? Changes in the application might require modifying multiple, step-based definitions in Cucumber, increasing maintenance effort compared to Cypress/Playwright's direct commands.
  4. Wasted Potential: Using Cucumber essentially reduces Cypress and Playwright to regular test automation tools, neglecting their capabilities for in-depth testing. Cypress and Playwright offer fine-grained control over browser interactions. By using Cucumber's higher-level steps, you lose the ability to write concise and maintainable tests directly with Cypress/Playwright commands.
  5. Duplicate Step Implementation: The Cucumber test automation approach can introduce complexities by adding an abstraction layer for BDD Gherkin steps. Additionally, different testers or developers may reinvent the wheel and conflate the code repository by rewriting duplicate step implementations.


Behaviour Driven Development (BDD) was introduced to address cross-team collaboration issues. However, Cucumber itself might not be the silver bullet. Instilling more professional discipline is likely a more effective solution.


Note: This article is based on my personal professional experience spanning 2 companies and 3 projects, as well as references to the article: https://filiphric.com/cucumber-in-cypress-a-step-by-step-guide

#Cucumber #BDD #cypress #playwright #testautomation

Jia T.

Software Development Engineer in Test / SDET / API Automation / Selenium WebDriver / Python

9 个月

Interesting article. I prefer a BDD tool on top of another tool like Playwright or Selenium for the sake of easy to read gherkins syntax when there’s a failure. BDD is kind of like TDD for QA automation. You write the gherkins syntax first. Then write the test code underlying gherkins to test the pass / fail scenarios. This takes the mystery out of test errors. It democratizes test running so that many stakeholders can execute the tests and understand the test results. What’s your take? Josh Schneider Ben C.

回复

要查看或添加评论,请登录

Er H.的更多文章