That’s right. Your eyes do not deceive you! There are two SpecsFor releases today! It’s BOGO Friday, read on to find out why!

SpecsFor 6 Final Released

SpecsFor 6 has been hanging out in preview form for nearly 4 months! I sort of lost track of the fact that I hadn’t published the final version.

Anyway, 6 Final is now out there, which includes .NET Core support. If you want to know more about this update, check out this really old post. For the most part, this version should be compatible with your existing SpecsFor projects, sans SpecsFor<MVC>, which is heading towards retirement.

SpecsFor 7 Preview Released

That brings us to SpecsFor 7. This version takes the first steps towards making SpecsFor more flexible. Thanks to the awesome contributions of Catchco developer Robert “I’m too good for social media!” Simmons, the core of SpecsFor is now IoC container agnostic! We’re shipping two official packages now, one for StructureMap, and one for Autofac. Creating your own adapter for other frameworks is actually fairly easy. Maybe Rob will write a guest post illustrating the process. Maybe showing integration with Lamar, perhaps?

If you’d like to see another container officially supported, feel free to submit a pull request!

We did remove several things from the v7 release. A lot of it was cruft that the project has picked up over the better part of a decade. Some features will probably be added back once I realize that I actually needed them…. ?

If you find something missing, drop an issue here on Github, and I’ll see about adding it back before v7 final is released.

Installing SpecsFor 7

There are now 4 SpecsFor packages you can choose from:

  • SpecsFor.Core – This is the heart of SpecsFor. You shouldn’t install this directly unless you plan to write an adapter for a different IoC container.
  • SpecsFor.StructureMap – If you want to use StructureMap’s automocking container, install this. If you’re using SpecsFor today, this package is what you want.
  • SpecsFor.Autofac – This is the package you want if your main project uses Autofac.
  • SpecsFor – This is now just a meta package for SpecsFor.StructureMap. It exists just to make it easier to upgrade. At some point this will be the “kitchen sink” package that pulls in all the test helpers and conventions as the core of SpecsFor is refactored further..

No matter which package you install, you will still derive from the base SpecsFor<T> class, just like you do today. The only thing that changes is which using statement you add:

using Moq;
using NUnit.Framework;
using Should;
// Just "use" the namespace for whichever package you installed! 
using SpecsFor.StructureMap;

namespace SMTests
    public class WidgetSpecs
        public class when_starting_a_widget : SpecsFor<Widget>
            protected override void When()

            public void then_it_sets_the_status_to_running()

            public void then_it_raises_an_event()
                    .Verify(x => x.Publish(It.IsAny<WidgetStarted>()));

There is one issue with the current beta release: you must manually install both the Microsoft.NET.Test.Sdk and NUnit3TestAdapter packages. If you don’t, the test runner won’t see your specs. I’m trying to find a way to bake this in to SpecsFor, but I’m coming up empty. Help is appreciated!

What’s Next?

I would like to get the whole Microsoft.NET.Test.Sdk dependency issue squared away, but I don’t know if that’s possible. .NET Core is still a mess in this area.

After that, the original roadmap for SpecsFor vNext still applies. I would love to get things broken up where both xUnit and NUnit work.

If no major issues are reported, I plan to release v7 final early next week. Someone please remind me if I forget. ?

Thanks again to Catchco and Robert “what’s a twitter?” Simmons. This release wouldn’t have happened without your contributions!