Once your cucumber projects get to a certain size you almost certainly start to think about moving away from monolithic steps files and toward a more object based approach.
This blog post describes how you might go about doing this and is definitely worth a read.
So, I wanted to have a project structure something like that depicted below:
/~features/ / /~examples/ / / /~step-definitions/ / / / /-steps.rb / / /-example.feature / /~support/ / / /-env.rb/ / / /~objects/ / / / /-myobjects.rb
And the good news is that this worked fine when I ran my cukes as follows:
cucumber -p default
However, when I ran with a specific feature it blew up as it failed to load my custom objects (myobjects.rb).
cucumber -p default features/examples/example.feature
uninitialized constant MyCustomObject (NameError)
So like every good hacker I started to delve down into the innards of the Cucumber runtime code, which whilst interesting was unnecessary had I read the help!!!
-r, --require LIBRARY|DIR 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. This option can be specified multiple times.
Note if you run a feature with tags then all code under /features will be pulled in, as when you run with no specificity.
So to always include all your code under /features, but still run a single feature - do the following:
cucumber -p default --require features features/examples/example.feature