The final build of SpecsFor.Mvc 4.0 is live on NuGet.  Here’s a recap of what’s changed.

[more]

Breaking Change: SpecsFor.Mvc is now built against ASP.NET MVC 5.2.  Remember, your web project does not have to be on 5.2 in order to use SpecsFor.Mvc, just your spec project.

MvcWebApp.BrowserDriver now returns a RemoteWebDriver rather than just IWebDriver.  This allows you to access additional capabilities from the underlying Selenium WebDriver.

Pluggable conventions! This has been on my roadmap for eternity, and it’s finally available:

config.UseConventions<MyCustomConventions>();
public class MyCustomConventions : IElementConventions
{
    public By FindDisplayElementByExpressionFor<TModel, TProp>(Expression<Func<TModel, TProp>> property) where TModel : class
    {
        ...
    }

    public By FindEditorElementByExpressionFor<TModel, TProp>(Expression<Func<TModel, TProp>> property) where TModel : class
    {
        ...
    }

    public By FindValidationSummary()
    {
        ...
    }

    public bool IsFieldInvalid(IWebElement field)
    {
        ...
    }
}

Out of the box, SpecsFor.Mvc uses the built-in ASP.NET MVC conventions for locating elements based on IDs.  However, if you do not render your UI using the standard HtmlHelpers (such as IdFor, TextBoxFor, etc.), you can still use SpecsFor.Mvc as long as there is some strongly-typed convention that you can plug in.  If you do everything dynamically, sorry, this isn’t the framework you’re looking for!

FluentField<T> now supports asserting off its value fluently:

SUT.FindFormFor<LogOnModel>()
    .Field(m => m.UserName).ValueShouldEqual("[email protected]")
    .Field(m => m.Password).ValueShouldEqual(string.Empty);

The temporary directory that your application is published to can now be overridden.  This makes it possible to spin up multiple integration hosts with multiple websites for more advanced testing scenarios.

var site1Config = new SpecsForMvcConfig();
site1Config.UseIISExpress()
    .With(Project.Named("Website1"))
    .WithTemporaryDirectoryName("Website1TempDir");

var site1Host = new SpecsForIntegrationHost(site1Config);

var site2Config = new SpecsForMvcConfig();
site2Config.UseIISExpress()
    .With(Project.Named("Website2"))
    .WithTemporaryDirectoryName("Website2TempDir");

var site2Host = new SpecsForIntegrationHost(site2Config);

site1Host.Start();
site2Host.Start();

You cannot directly utilize MVC 5.1’s attribute routing from a test project due to some nasty infrastructure in that stack, but that’s ok, because SpecsFor.Mvc now has a workaround.  Just call the BuildRoutesUsingAttributeRouting… helper method, and point it at your web project:

site1Config.BuildRoutesUsingAttributeRoutingFromAssemblyContaining<HomeController>();

Similar to SpecsFor, SpecsFor.Mvc now has a friendly post-install page to help you get started:

There are also numerous improvements to help you get up and running with less pain:

• An exception is thrown if you forget to specify a BrowserDriver. 
• The Selenium WebDriver executables are now pulled in via external NuGet packages.  These packages have a much better mechanism of acquiring and referencing the WebDriver executables than SpecsFor.Mvc previously had.
• SpecsFor.Mvc now checks for the required version of Microsoft Build Tools when you install the NuGet package.  If they are not installed, you’ll get a nice warning and some instructions on how to install them. 
• SpecsFor.Mvc now uses the latest version of MSBuild.  This should eliminate a lot of strange cases where a project compiles fine in Visual Studio but doesn’t publish correctly when tests are executed.
• Better output from SpecsFor.Mvc if the publish step fails.  This should make it easier to troubleshoot When Things Go Wrong.

Please let me know if you run into any problems after the update.  The fastest way to reach me is via Twitter: @matthoneycutt.