cucumber-ruby: --require not being honoured with --dry-run
Summary
Cucumber does not honour the -r flag, and Cucumber provides no way load *.env.rb files during dry runs. From what I understand, cucumber ignores env files due to interactions with Rails. Why this option is not configurable is a mystery as not every Ruby project is a Rails project.
The --require option has the following help text: (emphasis mine)
Require files before executing the features. If this option is not specified, all *.rb files that are siblings or below the features will be loaded auto-matically. Automatic loading is disabled when this option is specified, and all loading becomes explicit. Files under directories named “support” are always loaded first.
I am not sure how much more explicit I can be. Sure I could add another rb file and require my env file, but that brings up 2 more problems:
- I need to then keep track of every env file and its location in the directory structure.
- Cucumber uses load instead of require, so I will get spammed with re-declaration warnings.
Expected Behavior
Given I start cucumber is started with the following:
cucumber -d -r features/support/env.rb
Then env.rb should be loaded.
Current Behavior
Cucumber does not honour the -r option:
cucumber -d -r features/support/env.rb
Code:
Features:
* features/alarms.feature
* features/.... etc.
Possible Solution
Cucumber should honour the -r option. Cucumber should allow a configurable option for the env.rb loading behaviour for dry runs. If neither of the above is acceptable, then Cucumber should use requires instead of loads as per #1043 as a work around.
Steps to Reproduce (for bugs)
- Run cucumber with the dry run option, and the -r option set to an env.rb file
- See cucumber not loading the file.
Context & Motivation
I just want to do a dry run so I can find unused steps. I don’t see why Rails specific behaviour should affect non-Rails usage. < Providing context helps us come up with a solution that is most useful in the real world> Cucumber should be a general purpose BDD testing suite, not a Rails specific one.
Your Environment
- Version used: 3.1.2
- Operating System and version: Ubuntu 14.04 x64
Other notes
In general the loading of files by cucumber is not very well defined. We know that files in support folders are loaded first, but beyond that it is a mystery. I have had issues with tests randomly starting to fail because cucumber decided to load xyz.rb before env.rb. I can’t require env.rb because of #1043
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 21 (13 by maintainers)
I don’t need them at all, but cucumber still has to load any non-env files, and any code not inside a step or method would still get executed, even during a dry-run. So if env,rb sets @config then when my_setup_helper.rb tries to access @config[:some_var] it will get a no method error.
I understand that perhaps my issue is unusual, but I am working on a fairly old codebase (we just upgraded from cucumber 2.4 to 3.1 last month, and we have been using cucumber since at least 1.3) so there are some instances where we might be doing something that is a code smell.
Cleaning up the .rb files is in the works, but removing unused step defs is a bigger priority since they take up majority of the execution time during cucumber’s startup. After monkey patching cucumber to work around the env problem, it looks like I have 239 unused step defs spread out over dozens of files. You can maybe grasp the size of repo I am working on.
Not sure if you have already past feature cut for cucumber 4, but adding env files into dry runs along with a note about using exclude to maintain previous behaviour seems like a small change. If the only logic around loading is only controlled by that one file you mentioned, then the change would be 1 line of code.
Ironically I am the sole maintainer of site_prism. So if you think the issue is there, open an issue there, we can work in a cucumber stack
I’d like to see us do something to support your use-case in 4.0 @dpsi, I don’t think it’s too late. If you think it’s only a minor change @danascheider why don’t we go for it?
As you’ve recognised, @dpsi, the current behaviour around requiring files is kinda crufty and incoherent. I’d love this to get some attention for 5.0 if you were interested in helping us spec it out in a more holistic / comprehensive manner.