Best way to execute identical test scenarios using both Selenium and headless browser in Cucumber

Other Questions Headless Browser
1

I’m working on automated testing for web apps using Cucumber framework. Right now I have test steps configured to work with a headless browser setup, which runs fine for most cases. However, sometimes I need to execute the same test scenarios using Selenium WebDriver instead.

I’m thinking about two different ways to handle this:

  1. Modify existing step definitions to check a configuration flag and execute different browser actions based on that setting
  2. Create duplicate step definition files for each browser type and load the appropriate set during test execution

Which approach would be better for maintaining code and avoiding duplication? Has anyone dealt with this kind of multi-browser setup before?

2

Go with option 1 - the configuration flag approach. I’ve done this before and it works great. Set up a driver manager class that picks either headless or regular Selenium based on your environment variables or config files. The trick is creating a common interface for browser interactions so your step definitions don’t change at all, no matter which driver you’re using. You get one set of test scenarios but can switch execution modes whenever you need to. This saved us tons of time debugging - when headless tests failed, we’d run the same scenario with a visible browser to see what was happening. Way less maintenance than duplicate step files, and you won’t go crazy trying to keep two codebases in sync every time you change test logic.

3

Opt for the configuration flag approach rather than duplicating step definitions. Managing separate step files can quickly become cumbersome—each modification in test logic needs to be replicated, leading to potential oversights.

A more efficient method is to implement a wrapper class managing all browser interactions. This class determines which driver to utilize based on the configuration, while your Cucumber steps remain agnostic to whether it’s executing on headless Chrome or standard WebDriver. You can set this up using a property file or environment variable that is read at the start of the tests. This enables you to run the same test suite across various browser configurations in CI without modifying the underlying code.

4

i agree with the factory pattern! having one set of steps and just changing the driver config makes things less messy. trust me, keeping it in one place is so much better than having doubles. way more maintainable!