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.