Organising code in Specflow steps

Question

I understand from Techtalk that coupling step definitions to features is an anti-pattern. However I am wondering how to organise my step definitions so that I can easily see in the code what steps go together.

For example should I create a code file for each Feature and a separate file for steps that are shared? or should I have a code file for a set of features?

Answer 1

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 Givens for setting up test data
• DataAssertionSteps.cs - The Thens 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"?