Skip to main content

I no longer build C# apps

Okay so the title is slightly misleading, I'm still writing code in C# (.Net) but I'm no longer manually building the solution inside Visual Studio, no F5, no Ctrl+Shift+B...

You might be thinking huh?

What I mean is I no longer go round the continual cycle of write code, compile code, test code, refactor code etc. We've managed to remove the compile & test phases from the development process and I can't elaborate how liberating this is.

This has been achieved by using a continuous testing framework - tests are executed as you write the code. I found this article back from 2007 stating all the benefits you'll get from using such a framework - 'It’s turning the knob on Test Driven Development up to 11' - so true...

I'm currently working in an environment where the main constraint is not the tools we're using but the underlying OS. We're stuck with 32 bit Win XP machines for at least the short to medium term and our biggest problem is Out of Memory exceptions when compiling the code-base. This is 'by design' apparently, I understand why this is happening but it's still damn annoying and we wanted a way to reduce it. This is where I've found a continuous testing framework and an external triggered build process has really helped to reduce the number of OOM exceptions. Put simple the number of full builds has been reduced and therefore the number of OOM exceptions has also been reduced...

So which continuous testing framework are you using?

nCrunch developed by Remco Mulder, it's currently free whilst in beta.

The only other product I know about right now is Mighty Moose (by Greg Young of DDD fame). Previous to nCrunch I would have used DotCover to runs tests manually, but this has now been un-installed - I did hear on the grape vine that JetBrains are planning to have something out in the new year, hopefully dotCover will be upgraded. nCrunch doesn't currently support Silverlight which isn't a problem as we're using Project Linker to target the code base for both WPF & Silverlight platforms - nCrunch is automatically covering all the tests in the WPF (desktop).

nCrunch has everything I need, using the code from my previous post about Rx and the RefCount operator, these are the features and windows I'm currently using:

Syntax highlighting - you can see from the following screenshot the code is annotated with coloured icons on the left hand side:
Green indicates codes under test:
Black indicates code not under test:
The above black indicator shows there aren't any tests that are subscribing to the Listen method and receiving updates.

Red indicates code that failed as part of a one or more tests:
Tests are also annotated with icons on the left, but this time the failing line is highlighted with a red 'x':, hovering over the icon gives details of why the test failed - As you can see nCrunch has support for MSpec as well:
Test Window - Gives fast up-to-date info on failing tests:
It can also show passing tests:
Metrics Window - Allowing me to see where coverage is missing - a higher level view of the info provided whena file is open in Visual Studio:
Risk/Progress Window - not quite sure yet of the full benefit, but it does give a nice big binary (red\green) status of all the tests:
As I said at the start I'm no longer building the code manually this happens all automatically, the only time I ever hit F5 how is to run up the app to investigate a particular test problem...

A big shout out to @HamishDotNet for introducing us to nCrunch and also to @LordHanson for sorting out the external build process...


  1. AFAIK there's also
    NCrunch is probably the best one

  2. Good to know, I also found Giles -



Post a Comment

Popular posts from this blog

Showing a message box from a ViewModel in MVVM

I was doing a code review with a client last week for a WPF app using MVVM and they asked ' How can I show a message from the ViewModel? '. What follows is how I would (and have) solved the problem in the past. When I hear the words ' show a message... ' I instantly think you mean show a transient modal message box that requires the user input before continuing ' with something else ' - once the user has interacted with the message box it will disappear. The following solution only applies to this scenario. The first solution is the easiest but is very wrong from a separation perspective. It violates the ideas behind the Model-View-Controller pattern because it places View concerns inside the ViewModel - the ViewModel now knows about the type of the View and specifically it knows how to show a message box window: The second approach addresses this concern by introducing the idea of messaging\events between the ViewModel and the View. In the example below

Implementing a busy indicator using a visual overlay in MVVM

This is a technique we use at work to lock the UI whilst some long running process is happening - preventing the user clicking on stuff whilst it's retrieving or rendering data. Now we could have done this by launching a child dialog window but that feels rather out of date and clumsy, we wanted a more modern pattern similar to the way <div> overlays are done on the web. Imagine we have the following simple WPF app and when 'Click' is pressed a busy waiting overlay is shown for the duration entered into the text box. What I'm interested in here is not the actual UI element of the busy indicator but how I go about getting this to show & hide from when using MVVM. The actual UI elements are the standard Busy Indicator coming from the WPF Toolkit : The XAML behind this window is very simple, the important part is the ViewHost. As you can see the ViewHost uses a ContentPresenter element which is bound to the view model, IMainViewModel, it contains 3 child v

Custom AuthorizationHandler for SignalR Hubs

How to implement IAuthorizationRequirement for SignalR in Asp.Net Core v5.0 Been battling this for a couple of days, and eventually ended up raising an issue on Asp.Net Core gitHub  to find the answer. Wanting to do some custom authorization on a SignalR Hub when the client makes a connection (Hub is created) and when an endpoint (Hub method) is called:  I was assuming I could use the same Policy for both class & method attributes, but it ain't so - not because you can't, because you need the signatures to be different. Method implementation has a resource type of HubInnovationContext: I assumed class implementation would have a resource type of HubConnectionContext - client connects etc... This isn't the case, it's infact of type DefaultHttpContext . For me I don't even need that, it can be removed completely  from the inheritence signature and override implementation. Only other thing to note, and this could be a biggy, is the ordering of the statements in th