Mmmm-Crunch

A few months back I started hearing about the concept of continuous testing, more specifically the tools Mighty Moose and AutoTest.Net. Unfortunately the moose isn’t freely available and as it builds on the open source AutoTest, the latter package isn’t so capable or polished. Fortunately I then heard of NCrunch which is ready for anyone to download and start using, and seems to have similar goals with code coverage indicators, only compiling the smallest amount of changed code possible etc.

Obviously I was keen to install it, but given my machine’s love of hanging Visual Studio, and the largeness of the solutions I tend to find myself in I left it in disabled mode for a while. With some recent work letting me hone in on a smaller set of project files I decided to give it a try. Initial impressions were a little mixed. It was looking pretty good for most of the projects in my solution, but a handful failed to build, sadly including the one I actually needed to work on. The NCrunch test runner stated that it couldn’t find the dll that it was trying to test, but from what little I could see everything was where it should be. With work to do I decided to turn NCrunch off and get on with it in the more traditional TDD style.

Eventually of course you move onto a different bit of work, and as that happened I realised that I could probably give NCrunch another go with the different assemblies I had moved on to. Second impressions were very favourable with indicators telling me that code was failing then passing as I worked, with far less compilation stuff happening than when using the built in MsTest test runner. The big red failure marks on the other project files were still bugging me though. I opened up all of the windows that I could find in the NCrunch menu and saw that there was a configuration pane which lets you tweak a few settings per project. One of these settings is CopyReferencedAssembliesToWorkspace, this has warnings that it may negatively impact performance, but, joy of joys, it got one of my failing projects to build. Then it got 3 of them to build, and just 1 was left failing. For the final failure I needed to set the same property again, but on the production code class rather than the test itself.

Sadly, whilst you can specify which tests to run and which to ignore, NCrunch doesn’t seem to have any facility that I can see to tie that in to what we have set in the MsTest test list editor window and associated vsmdi file. That is all still there to be run at will though, so I can leave that to the CI server and just the odd local run when I check code in and out of source control, and stick to NCrunching whilst churning through the TDD cycle.