Running identical Cucumber test scenarios with both Selenium WebDriver and headless browser automation

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 solution, which runs pretty fast and works great for most cases.

But sometimes I need to run these same test scenarios using Selenium WebDriver with a real browser to debug issues or see what’s actually happening on screen.

I’m thinking about two ways to handle this:

  1. Make each step definition smart enough to detect which browser type to use based on some configuration setting
  2. Create separate step definition files for each browser type and load the right ones depending on my test run

Which approach would you recommend for this kind of dual browser setup?

2

Option 1 is way more maintainable, but I’d tweak the implementation. Don’t make each step definition handle browser detection - create an abstraction layer at the driver level instead. I use a WebDriverManager class that returns either headless or regular WebDriver based on a command line parameter or config setting. Your step definitions stay clean and focused on test logic, not browser management. You can switch between modes without touching any test code. Just heads up - headless browsers behave differently sometimes. I’ve seen viewport size differences and weird file download handling, so you’ll probably need some environment-specific configs for those edge cases.

3

I’d go with option 1 too after doing this on several projects. Set up a factory pattern or config class to handle the browser switching - I usually use environment variables or config files to control which browser gets spun up. Watch out for headless browsers though - they act differently than full browsers, especially with JavaScript timing and element visibility. You’ll probably need conditional waits or assertions in your step definitions for these edge cases. Saved me tons of debugging time when tests would pass headless but fail in regular browser mode.

4

i’ve tried both methods, but option 1 is def the way to go. keeps things organized and avoids duplicated code. Just make sure to handle the config carefully!