Today, I took the first steps in laying out a roadmap for future work on both SpecsFor and SpecsFor.Mvc. 

[more]

First, I created a public Trello board to track ideas.  You can review the ideas I’ve tossed up there and vote on what you think is most important.  I see a couple of big themes that I plan to focus on in the short-term.

Making SpecsFor.Mvc Truly Painless

My lofty goal for SpecsFor.Mvc was to enable anyone to create full end-to-end tests with the same ease as unit tests.  It’s hard to argue that the project hasn’t failed to achieve this goal.  I want to rectify that by:

  • Handling process lifetimes better – SpecsFor.Mvc needs to spin up several processes in order to run your tests.  Depending on the test runner you use, it’s quite easy to end up with orphaned Selenium Web Driver, IIS Express, and even web browser processes.  These orphaned processes then cause later tests to fail, which in turn causes frustration for you, the developer.  I have a rough idea in mind that would ensure that orphaned processes are cleaned up correctly no matter what your test runner does.
  • Better documentation – There’s really no documentation at all for SpecsFor.Mvc aside from what I’ve posted on this blog.  That has to change.  My plan is to focus on scenario-based documentation first, showing you how to do common things with SpecsFor.Mvc.  With that, I doubt there will be a need for in-depth documentation about all of the various moving pieces.
  • Better “new project” workflow – New developers should have to work to make SpecsFor.Mvc not work correctly.  By creating a better NuGet package, providing better error-checking for common configuration problems, and better, more useful errors and suggestions, I think we can steer people towards the happy path where their tests only fail for the right reasons.
  • Improved test-runner and test-framework compatibility – Historically, I’ve mainly used TestDriven.net to run my SpecsFor.Mvc tests, and I’ve given little thought to how well it works for other test runners.  I also haven’t tested heavily with other frameworks besides SpecsFor and NUnit.  At a minimum, I want to be sure that SpecsFor.Mvc works well with Resharper and the standard VS.NET test runner while using NUnit and SpecsFor, but ideally I’d like to devote more time to making sure it works well with other frameworks, too, like MS Test.
  • First-class build server support – Getting SpecsFor.Mvc to work well with build servers like TeamCity isn’t documented anywhere, and it isn’t all that straightforward.  I need to add documentation and find ways to streamline setup on build servers.

Handling (More) Common Testing Pain with SpecsFor

I’m quite happy with where SpecsFor is right now with the exception of documentation.  Again, I want to create scenario-based documentation that shows how to tackle various scenarios “the SpecsFor way.”  After that, my plan is to focus on more common pains that I’ve encountered in recent projects.

  • Improve ShouldLookLikePartial and Looks.LikePartialOf – Both of these methods are quite useful, but they both utilize anonymous objects, and that means they don’t have compile-time safety, nor are they refactor-friendly.  I want to create versions that achieve the same thing (comparing only a subset of an object’s properties), but in a strongly-typed way.  The solution that’s been suggested (and that I like) is to use lambda expressions.
  • Ship common conventions – SpecsFor’s convention system rocks (ok, yes, I’m biased).  I have made heavy use of it in creating integration tests that utilize NHibernate or Entity Framework underneath.  In every case, I’ve create a TransactionScope-based convention that undoes changes to the underlying database after each spec.  That sort of thing is so common that it should really be baked in.  I want to add that, and possibly other optional conventions, to SpecsFor.
  • ASP.NET MVC-specific helpers – I’ve historically made use of MVContrib’s TestHelpers when unit testing my ASP.NET MVC projects, but MVCContrib is effectively dead.  I also don’t like that it forces a dependency on Rhino Mocks, when SpecsFor itself is based on Moq.  I want to create a separate SpecsFor.Helpers.Mvc library that obsoletes the helpers from MVCContrib, and that goes even further in eliminating common ASP.NET MVC unit-testing pains.
  • More Should helpers – There are still some things that Should and the SpecsFor extensions can’t handle, such as comparing lambda expressions.  I want to make additional helpers to address these pain points.

And Long Term…

There’s even more that I’d like to do on both projects.  I’d like to make SpecsFor compatible with MS Test, so that pure-Microsoft shops can start taking advantage of it.  I’d like to make SpecsFor.Mvc use Ghostdriver out of the box, so that you can run tests quickly without a full browser.  I’d like to investigate tooling and add-ins for Visual Studio and/or Resharper to streamline the use of each project.  But, I guess I should start with the (epic) list above. 

If you’d like to help out on the project, you can start by reviewing the Trello board and voting on the issues you care about. If you’re using either project and have run into something painful, please let me know, and I’ll get it added to the Trello board so that it can be prioritized.  And if you’d like to help write some code, let me know!  I’m going to start breaking some of the cards down into tasks and smaller stories that are more-friendly to new developers, so there will be plenty to do regardless of your skill level!