Step Organisation

How do you name step files? What to put in each step? What not to put in steps? Here are some guidelines that will lead to better scenarios. If you are new to steps and the general syntax, please read Feature Introduction first.

Grouping

Technically it doesn’t matter how you name your step files and what steps you put where. You could have one giant file called all_steps.rb and put all your step definitions there. That would be messy.

We recommend creating a steps.rb file for each domain concept. For example, a good rule of thumb is to have one file for each major model/database table. In a Curriculum Vitae application we might have:

• employee_steps.rb
• education_steps.rb
• experience_steps.rb
• authentication_steps.rb

The three first ones would define all the Given-When-Then step definitions related to creating, reading, updating and deleting the various models. The last one defines step definitions related to logging in and out.

If you follow this pattern you also avoid the Feature-Coupled Steps antipattern.

Step state

It’s possible to keep object state in @variables inside your step definitions. Be careful about this as it might make your steps more tightly coupled and harder to reuse. There is no absolute rule here – sometimes it’s ok to use @variables. You can follow a longer discussion here.