Structure my specs

Project Organization

How should you structure your specs? Great question! There's no absolutely-right or absolutely-wrong answer here. Here's the method that I've found to work well.

First, organize your specs into two projects: one for fast-running unit tests, and a second for slower-running integration tests. If you are also doing end-to-end tests, put those in a third project.

Next, within the project, create a folder for each project you're going to write specs for. If your solution contains projects named Acme.Core, Acme.Data, and Acme.Utility, create folders named Core, Data, and Utility.

Within each of those folders, mirror the namespace/folder structure of the project you're going to test. If the full name for a class is Acme.Core.Factories.WidgetFactory, its unit tests should be in Acme.UnitSpecs.Core.Factories.WidgetFactorySpecs.

File Structure

Again, there are no right or wrong ways to structure your specs. SpecsFor is flexible and can accommodate whatever conventions make sense to you.

That said, here's the approach that works for me. Let's assume you are going to write specs for a class called WidgetFactory. Create a new class named WidgetFactorySpecs. Now, within this class, create a nested class for each scenario you are going to test. For example, if the scenario is 'when creating a new widget', you would create a nested class named 'when_creating_a_new_widget.' Make your scenarios derive from either SpecsFor directly or from a common spec base class that establishes common state.

With this approach, you can easily and quickly toggle back and forth between a class and its specs, and you can run all the specs for a particular class directly from the file containing them.