It's a little earlier than I planned it, but NCrunch 1.38b is now stable and ready for release!

Before going into detail on all the good stuff in this release, I first want to say that I originally hoped to put much more in it.  My original plans put the release date around this middle of this month, which would have made room for a few extra features and compatibility improvements.  Unfortunately 1.37b contained a performance problem that was affecting a large number of people, and with the release of the VS11 Beta last week it made sense to bring 1.38b forward.  Silverlight support is something I also still hope to get to very soon.

So! What does 1.38b have to offer that's special? Let's take a look ...

Custom Engine Modes

NCrunch now allows you to create your own custom engine modes on a per-solution basis.  The customised engine modes can control which tests are automatically queued for execution, using very configurable criteria.  This makes it possible for you to create different engine modes for your solution that suit your working style at the time.  For example, you may have an engine mode designed to automatically run all tests in the solution except for those that have a category of 'Integration'.  You could then have a different engine mode that would run all tests provided their name matches a regular expression, or they have been impacted by changes made to the codebase.  This is a very powerful feature, opening the door to using NCrunch as a 'partially continuous' test runner.

The ability to customise engine modes makes some interesting changes to the way that NCrunch can be used.  Up until now, the normal way to handle heavy-weight or resource intensive integration tests has been to ignore them using NCrunch or to keep NCrunch out of the 'Run all tests automatically' mode.  A cleaner approach to this is now possible, as you can create your own category to adorn these tests then instruct NCrunch never to run them automatically.  This means you can have all the advantages of continuous unit test execution while still retaining the ability to run integration tests manually with inline code coverage and performance analysis on-demand.

Recognition of Impacted Test Analysis

Since its first public release, NCrunch has had the ability to analyse changes that are made to a codebase and identify tests that are impacted with these changes.  Up until now, this impact status has been mostly invisible with the impacted tests simply sitting in the processing queue with a higher priority.

NCrunch 1.38b contains several changes in this area to make the concept of an impacted test more visible and meaningful.  You'll notice that impacted tests are now shown with a little 'i' in the Tests Window.

The 'Impacted' status flag can also form part of the criteria in customising engine modes, and as such a new pre-configured engine mode has been introduced: 'Run impacted tests automatically, others manually'.

As NCrunch's impact analysis is still fairly rudimentary, this new engine mode is highly experimental and to be used at your own risk.  Regardless of how sophisticated a tool's impact analysis is, it will never be perfect and this can result in tests not being run when they should be.  Still, this can be useful if you're looking for a more resource-friendly approach to continuous testing with a lower certainty of overall test results.  I'm interested in hearing more feedback about this impact analysis to help me determine if this is an area NCrunch should be further extended towards.

The impacted status of tests is now also saved to NCrunch's cache file between instances of Visual Studio or during an engine reset.  This means the NCrunch engine should feel much more responsive shortly after it is enabled as it will have more information with which to make prioritisation decisions.

Corner Indicator

By popular demand, NCrunch now has a corner indicator that gives information about the workings of the engine while the system is enabled.  This should help reduce the reliance on big clunky dockable windows and generally give a cleaner feel to the crunching experience.

The new indicator is designed to try and show the maximum amount of useful information possible in the smallest possible space.  This information is as follows:

• The letter/number in the middle gives the 'most relevant' metric at the current point in time.  If a build is in progress, this will show 'B'.  If NCrunch is starting up and loading projects, this will show the number of projects that still need to be loaded (count down!).  If a build failure exists, this will show the number of projects failing to build.  If test failures exist, this will show the number of tests currently failing.  If tests are queued for execution, this will show you how many tests are still in the queue.
• The shade of the above letter/number is also used.  If it is faded, this means that the results being shown are not up to date and may not be accurate (for example, if a test recently failed but changes to the codebase may have fixed it).
• The colour of the outer circle gives context to the metric shown.  If build failures exist, the outer circle will be orange.  If test failures exist, it will be red.  If all is well, it will be green.
• The white spinners on the outer circle represent tasks that are being executed by NCrunch.  This means that if you have 5 sets of tests all running in parallel, then you'll see 5 spinners.

VS11 Beta Support

NCrunch 1.38b introduces full support for the recently released Visual Studio 11 Beta.  I'm not sure if there's much more to say here :)

Fixes and Compatibility Improvements

This version of NCrunch also brings with it another batch of fixes and compatibility improvements for many of the problems reported in 1.37b.  Worthy of note is a fix for a serious performance problem that was affecting a large number of people.  Overall, 1.38b is faster, more stable and more reliable than any NCrunch version before it (if this isn't the case, please do let me know!).

Anyway, that's enough nattering from me.  Go grab yourself the new build!