You’re creating your first SpecFlow project and you have no idea what you are doing. There are the feature files and step definitions that form the majority of your project. But SpecFlow also provides hooks and step transforms as well to help make life easier. On top of that you have some helper classes/methods to make your life even easier.
All of this is great stuff and you love what SpecFlow is helping you do but how do you organize all of these different things in your project?
Over the course of the last year or so I have introduced SpecFlow to a number of different teams and projects at my company. During that time I have noticed that every time the different type of SpecFlow artifacts (steps, hooks, etc.) are organized by the type of artifact. All of the step definitions go into a Steps folder. Any hooks go into a Hooks folder and so on. This approach makes it easy to answer a question like “Where are the step definitions?”
What I have found though is that organizing a project this way makes it easy to answer “Where are my step definitions?” but hard to answer “Does a step definition already exist for deleting a user account?”
This is because organizing the project by artifact type makes it easy for the various folders to become dumping grounds which in my experience is what seems to happen. The longer it takes to find whether something exists then the more likely it is that a new one will be created. Sometimes a new step definition is added to an existing file. Other times a new file is created with a single step definition in it. This effect is amplified even more if there are multiple teams contributing to the project at the same time.
When organizing your SpecFlow project I would suggest organizing the various SpecFlow artifacts based on the domain that they interact with and not the artifact type. This means that a step definition file that deals with user accounts for example would go under a UserAccount folder instead of a Steps folder. Any hooks or table transforms that deal with user accounts go into the UserAccount folder as well.
This structure gives you a much clearer understanding of your domain. Answering the question “Does a step definition already exist for deleting a user account?” becomes a lot easier at this point. As new team members or entirely new teams are introduced to the project it is clear what domain are touched and how the SpecFlow projects interacts with the actual systems.
Now not every file in a SpecFlow project fits nicely into this structure. In my experience though the majority of the files in the project will fall under a domain folder. The outliers can be put into a miscellaneous and/or helper folder. Even those over time may end up starting to form their own unique domains in which case they should be organized into their own separate folder.