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...
Labels:
Location: 11 Gunstor Rd, London Borough of Hackney, N16, UK

Comments

  1. Anonymous25 June 2012 at 07:39

    AFAIK there's also http://ox.no/software/continuoustesting
    NCrunch is probably the best one

    ReplyDelete
  2. awkwardcoder25 June 2012 at 09:07

    Good to know, I also found Giles - http://codereflection.github.com/Giles/

    ReplyDelete
  3. Stephanica24 April 2019 at 12:47

    https://sfdccodepractices.blogspot.com/2017/07/test-automation-logic.html?showComment=1556105093555#c5003221051350958331

    ReplyDelete

Post a Comment

Popular posts from this blog

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...
Post a Comment
Read more

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 ...
5 comments
Read more

WPF tips & tricks: Dispatcher thread performance

Not blogged for an age, and I received an email last week which provoked me back to life. It was a job spec for a WPF contract where they want help sorting out the performance of their app especially around grids and tabular data. I thought I'd shared some tips & tricks I've picked up along the way, these aren't probably going to solve any issues you might be having directly, but they might point you in the right direction when trying to find and resolve performance issues with a WPF app. First off, performance is something you shouldn't try and improve without evidence, and this means having evidence proving you've improved the performance - before & after metrics for example. Without this you're basically pissing into the wind, which can be fun from a developer point of view but bad for a project :) So, what do I mean by ' Dispatcher thread performance '? The 'dispatcher thread' or the 'UI thread' is probably the most ...
Post a Comment
Read more