Modules organization
When the project is started it's okay to have all the steps defined in a single .feature
file. However, as the project grows, it will be more efficient to split all the steps into meaningful groups in different .feature
files. This will make the project tests more logically organized and easier to maintain.
Grouping
Technically, it doesn't matter how .feature
files are named, or which scenarios are put in there. However, as the project grows, big .feature
files becomes messy and hard to maintain. Instead, we recommend creating a separate .rs
file for each domain concept (in a way that is meaningful to your project).
Following this pattern allows us also to avoid the feature-coupled step definitions anti-pattern.
Avoiding duplication
It's better to avoid writing similar step matching functions, as they can lead to clutter. While documenting steps helps, making use of regular and Cucumber expressions can do wonders.
Managing growth
As the test suit grows, it may become harder to notice how minimal changes to regular expressions can lead to mismatched steps.
TIP: We recommend using
Cucumber::fail_on_skipped()
method in combination with@allow.skipped
tag. The latter allows marking the scenarios which steps are explicitly allowed to be skipped.