A new release of SpecsFor.Mvc is now live on NuGet.  This release includes one simple, but important, enhancement as well as a few other minor improvements.

[more]

Area Support

One major oversight of SpecsFor.Mvc 1.0 was lack of support for Areas.  Well, that’s now fixed in 1.1.  First, you need to register the Area in your SpecsForMvcConfig class:

[SetUpFixture]
public class AssemblyStartup
{
    [SetUp]
    public void SetupTestRun()
    {
        var config = new SpecsForMvcConfig();
        
        //...snip...

        config.BuildRoutesUsing(r => MvcApplication.RegisterRoutes(r));
        //Just call RegisterArea with your AreaRegistration classes!
        config.RegisterArea<TasksAreaRegistration>();

        //...snip...
    }
}

Next, you must decorate the controllers in your area with the ActionLinkArea attribute from the Microsoft.Web.Mvc namespace of the MVC 3 Futures project (available via NuGet).  This is used by the strongly-typed ActionLink HtmlHelpers and other strongly-typed helpers, and it’s also utilized by SpecsFor.Mvc, which is built on the same underlying conventions.  You can check out the demo application in the SpecsFor solution for a working example.  SpecsFor.Mvc will likely expose this convention so that it can be customized beginning with the 2.0 release.

Testing Static Apps

Not all apps are well-suited for SpecsFor.Mvc’s embedded IIS Express host.  Maybe you have a Continuous Deployment environment that you want to point SpecsFor.Mvc at.  You could do this in 1.0 by directly assigning the MvcWebApp.BaseUrl property, but SpecsFor.Mvc 1.1 introduces the new UseApplicationAtUrl method:

[SetUpFixture]
public class AssemblyStartup
{
    [SetUp]
    public void SetupTestRun()
    {
        var config = new SpecsForMvcConfig();
        
        var config = new SpecsForMvcConfig();
        //Instead of this...
        //config.UseIISExpress()
        //    .With(Project.Named("SpecsFor.Mvc.Demo"))
        //    .ApplyWebConfigTransformForConfig("Test");
        //Use this...
        config.UseApplicationAtUrl("http://blah.com");

        //...snip...
    }
}

Do note that this method is not compatible with applying Web.config transforms.

FluentField Is Now Extension Method-Friendly

In version 1.0, FluentField maintained all of its state internally, meaning you did not have access to the underlying IWebElement, the form, or even the MvcWebApp instance the field was pulled from.  I’ve changed that in 1.1 (thanks, @KillaVanKells for the suggestion), so you can now write your own extension methods of off FluentField.  If there’s interest, I may stand up an official SpecsFor.Mvc.Contrib project for people to submit extension methods to.