The documentation on SpecsFor is sorely lacking.  Me (and another volunteer!) are working to fix that.  This is the first in a series of posts about SpecsFor, which will eventually make its way in to the official docs. 

In this post, I’ll show you how to add SpecsFor to your project using NuGet, and I’ll show you how I typically organize my specs.

[more]

What’s included?

SpecsFor is available as a NuGet package.  When you add it to a project, you get not only SpecsFor, but also several other things to help you with your testing:

• NUnit – SpecsFor is built on top of NUnit, one of the most well-established test frameworks for .NET.
• Moq – A simple, easy-to-use mocking framework.
• StructureMap.AutoMocking – SpecsFor uses this to create the class you wish to write tests against.  Note that you do not have to use StructureMap in your main project.
• Should – A set of extension methods for writing your test cases, like "x.ShouldEqual(5)."
• ExpectedObjects – A great library that overcomes the common testing challenge of comparing two complex objects (more on this in a future post).

Organizing Your Specs

There are many schools of thought on how your specs (or test cases) should be organized.  Some people opt for a separate test project for every project in their solution:

This approach will (obviously) double the number of projects in your solution though, and it can make it difficult to share test helpers you create.

Instead, I prefer to create only two project for my specs, regardless of how many projects my solution actually has: one for my actual unit tests, and one for my integration tests. 

Breaking things this way makes it easy to separate fast-running unit tests from slower-running integration tests.  It can also make life easier if you are using certain test runners, such as NCrunch, since your integration tests probably won’t play nicely if you execute them in parallel.

Within each spec project, I’ll organize things to mimic my solution structure.  That means that, in the root of each spec project, I have a folder for each non-spec project:

Within those folders, I’ll then create subfolders as needed to mimic the namespace and organization of the corresponding project.

If you are following along at home, let’s go ahead and make our spec projects. 

Creating Your Spec Projects

First, let’s create a solution folder (right-click on the solution, and choose "New Solution Folder") named Specs. 

Next, right-click on your Specs folder, and choose "Add New Project."  In the dialog that appears, find the class library project type:

The name of your project isn’t too important, but I typically use the pattern "SolutionName.UnitSpecs" and "SolutionName.IntegrationSpecs."

Repeat this process for your other spec project.  Your solution should now have two spec projects, like in the image we saw previously:

Now we’re ready to add SpecsFor!

Adding SpecsFor

SpecsFor is available as a NuGet package, so there are a couple of ways you can install it.  You could use the Visual Studio NuGet Package Manager Console, or you can use the GUI.  Let’s use the Package Manager Console.

In Visual Studio, go to the View menu, then select "Other Windows," then select "Package Manager Console."

This will open the Package Manager Console within Visual Studio:

Let’s install SpecsFor into each of our spec projects.  Run this command, and specify the full name of your spec project each time:

#Don't forget to change "SampleApplication1.UnitSpecs" to the name of your spec project!
Install-Package SpecsFor -ProjectName SampleApplication1.UnitSpecs

After some churn, you should have SpecsFor installed into both projects.  Over in Solution Explorer, expand each spec project, then expand their References folders.  Each folder should contain a reference to SpecsFor:

And there you have it!  Both projects are now ready!  In the next post, we’ll write our first spec!