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...

Read More

Understanding RefCount in Reactive Extensions

A couple of weeks ago @LordHanson & I ran into an issue converting a stateless async service exposed as an Rx cold observable to a connect-able hot observable. The issue was solved after a couple of hours, what follows is how we how got there.

The service is an Rx wrapper around the Caplin messaging API. The Caplin API is designed around the idea of opening a connection, subscribing on subjects and then receiving messages asynchronously - pretty standard and nothing unusual.

When used in an app where there's only ever one subscriber for a subject then a service designed around Rx cold observables is suitable - we had something similar to what's shown below, in this example I've substituted the Caplin part with an observable timer to spit out messages every second:

So this is a cold observable because every time the Listen method is called a new stream is created with it's own set of messages being published - Lee Campbell has a good explanation of hot & cold observables.

So when we went to a model where there would be multiple subscribers for a subject we needed to change the implementation, we now had to concern our selves with the idea of sharing the stream between multiple subscribers (threads). Under the covers the underlying Caplin connection was being shared between multiple threads this meant we didn't want the connection to be dropped just because one of the thread had disposed of it's observable instance, we only wanted connection to be dropped when ALL of the subscribers had disposed of their observable instances - we needed some kind of reference counting on the under lying stream...

We knew we had to create a hot connect-able observable using the Publish & Connect Rx extension methods - basically you create a connect-able stream by publishing and then explicitly connecting when you are ready to subscribe:

For us we wanted something a little more complicated - we needed our service to have only a single stream per subject, this stream would then be shared between multiple listeners (subscribers) and importantly as I have already said we needed ref counting on the stream. This is where we started to have problems.

We knew our service was going to cache the stream on a per subject basis, so that if a connection & subscription had already been made on a subject we'd return that instance:

We also knew we'd need a composite disposable so that we could remove the subject once it had been disposed:

Our issues were around how to use the Publish, Connect & RefCount Rx extension methods, specifically the following codes doesn't compile because the RefCount method is not exposed on the IDisposable interface, it's only exposed on the IConnectableDisposable interface:

What the documentation didn't make clear was the fact we didn't need the call to the Connect method. It only states:

 'Returns an observable sequence that stays connected to the source as long as there is at least one subscription to the observable sequence.'

It doesn't explicitly state it actually calls Connect for you under the covers, we were in fact very close to the solution:

Below are couple of MSpec fixtures, the first shows the underlying observable is a shared instance:

The second shows once the subscribers are disposed and new one created, the newly created one is a different instance:

With the following test results:

Read More

Getting MSpec working with Visual Studio 2012 RC & R# 7 EAP

These are the steps are used to get MSpec working with the release candidate for Visual Studio 2012 and the EAP for Resharper 7.

I'm using the build 64 (09/06/2012) of R# 7 EAP - latest releases can be found here.

Firstly, I have the following MSpec style fixture shown below, as you can see the Resharper icons aren't showing up on the left hand side:

The next step is to add the correct Nuget package for MSpec - you have to get the pre-release version, not the current production release. I installed it using the package manager console in Visual Studio - don't forget the '-Pre' suffix to get the right version of the package:

At this point you're probably thinking you're good-to-go, but there's one important step left - the pre-release MSpec assemblies have to be copied to the app data folder for Resharper. Luckily the MSpec guys have this in-hand and have created a set of batch files as part of the Nuget package installer. Browse to where the  Nuget package was installed for your solution and run the 'InstallResharperRunner.7.0 - VS2011' batch file:

You should then be seeing the following assemblies to the Resharper plugin folder:

Running up Visual Studio you should see the Resharper icons on the left hand-side and be able to run any MSpec fixtures, as you can see this one is failing :)

Read More