I tend to organize step definitions in a couple of ways, depending on how big the step definition files get.
Separate data and UI steps
I have lots of Given some thing exists in the database
steps, so I usually throw these into a file call DataSteps.cs. I also have lots of Then something exists in the database
steps and those go into DataAssertionSteps.cs.
All of my When I fill in some form field
steps go in FormSteps.cs. Anytime I need Then something in the form is enabled|disabled
or asserting that form fields have a certain value, I throw those into FormPresentationSteps.cs.
Separate Steps by Model
Sometimes my step definition files get very large, and I start moving step definitions into files related to a certain model. Say I have a Person
model. I might create a PersonSteps.cs file that is split into three regions:
[Binding]
public class PersonSteps
{
#region Given
// Given a person exists with the following attributes:
#endregion
#region When
// When something something about a Person
#endregion
#region Then
// Then a person should exist with the following attributes:
#endregion
}
Basically I start out with these files:
- DataSteps.cs - The
Given
s for setting up test data
- DataAssertionSteps.cs - The
Then
s for asserting that data exists correctly in the database
- PresentationAssertionSteps.cs - Just general stuff making sure the UI looks as itshould
- FormSteps.cs - Steps for manipulating forms
- FormPresentationAssertionSteps.cs - Making sure form fields have the proper values, are enabled/disabled correctly. Validation messages show up, etc.
- GeneralSteps.cs - A poorily named catch-all for stuff that doesn't fit in the above files. Maybe I should rename it "AndIShallCallItSomethingManagerSteps.cs"?