Coding and Dismantling Stuff

Don't thank me, it's what I do.

About the author

Russell is a .Net developer based in Lancashire in the UK.  His day job is as a C# developer for the UK's largest online white-goods retailer, DRL Limited.

His weekend job entails alternately demolishing and constructing various bits of his home, much to the distress of his fiance Kelly, 3-year-old daughter Amelie, and menagerie of pets.


  1. Fix dodgy keywords Google is scraping from my blog
  2. Complete migration of NHaml from Google Code to GitHub
  3. ReTelnet Mock Telnet Server à la Jetty
  4. Learn to use Git
  5. Complete beta release FHEMDotNet
  6. Publish FHEMDotNet on Google Code
  7. Learn NancyFX library
  8. Pull RussPAll/NHaml into NHaml/NHaml
  9. Open Source Blackberry Twitter app
  10. Other stuff

Unit testing WebForms With a Nod Towards MVC and MVP

Hi all,

For those of you who've had a read of my last post, I'm afraid it's enough of the gadget hackery and back to coding!  This time, I'm going to reflect on some work that I'm involved in with my sterling team-dudes in the office.

This last two weeks, we've been migrating chunks of a classic WebForms app to an MVP structure, with an eye to ultimately migrating across to MVC.  This post is going to look at the very first stage in this process - getting our UI and non-UI code split between a View and combined Presenter/Model, so that we can get this code under test.  Future posts are (hopefully) going to look at how we get clean up the messy combined Presenter/Model to leave a properly structured set of Presenters and Models, and how these should and should not be coupled to one-another.


Permalink | Comments (1)

Automating Test Coverage with PartCover, NUnit and Nant

Hi all,

I've been playing around recently looking at test coverage with PartCover - for those of you unfamiliar with PartCover, it's a free open source alternative to test coverage tools such as NCover or dotCover.

I should mention the following is all based on the existing PartCover tool, apparently there's a port in progress which resolves a couple of issues with the current PartCover (see, so I may be revisiting this topic in future as the port becomes stable.

So far I've mainly used PartCover through it's Browser GUI, but this is a manual process that I need to take time to regularly do. With an eye to automate things, there's also a command-line version of the tool, which uses the same configuration, but generates results out to a report file. If I can get this command into a Nant build file, then every time I commit my code into my repository, I can get Jenkins-CI (my continuous integration tool) to run Partcover over my newly checked in code. I could also potentially fail my build if I don't have a minimum percentage code coverage (though on its own it's important to point out that this is a very poor marker of test quality!).


Permalink | Comments (10)

Fhem DotNet Ingredients - Source Control, Build and Integration Tools

This post is the first in a series of posts talking about the ingredients that have gone into the project so far.  I'm still acutely aware that there's no public code yet, but as a sort of stalling tactic, let me talk about some of the things that have gone into the project so far.  This first part is a look back at the first few days of the project, way back in November last year.

If we use a bread-baking analagy (a crummy analagy, I know), these ingredients are the standard essentials whether you're making .Net web-bread or Java app-bread - things like a bread tin (source control), an oven (continuous integration tools), a rolling pin (build tools), etc.  My next few posts will look at some of the later ingredients in the process, such as the tools I'm using for testing, exception handling and event logging, isolation frameworks , dependency injection, etc.


Permalink | Comments (0)

TDD - It may be driven, but it's not exactly directed

As some of you might know, and this blog will attest, I've been talking about doing open source work with FHEM for some time now - around 3 or 4 months now I'd guess.  As of yet, nothing's been published, and this isn't good.  I'll be honest, there's not been a ton of work going into this project (around 5 to 10 hours a week), but still, 3 months and nothing to show for it?  What the hell!?

When I think about it, there seem to be two big reasons for this this, the first I'm going to talkabout in this post, and the second in an upcoming post.  Where my testing problems are concerned, to spoil the ending a little, it does involve BDD with Specflow, but we'll come to that.


Permalink | Comments (2)

Moq asserts - .Verify() vs .VerifyAll() and how VerifyAll can seriously hamper test readability

Hi all,

I've been looking at some tests we've been writing here today, and I think I've spotted a bit of an anti-pattern that I'd like to quickly draw out. In my experience, when I pick up existing unit tests there are three things I look at - what code is being exercised, do the tests pass when I run them, and crucially what is being asserted. Your assert is the one line of code that justifies te existene of the entire test. Getting this wrong can lead to a situation where even if you have 100% code coverage, you have no assurance that your code actually does anything useful at all.


Permalink | Comments (0)

Fhem DotNet - Let's Try That Again

Hi all,

I have a confession to make - my initial efforts to create a .Net FHEM front end have become mired in the deepest depths of geek porn - I've spent the last 2 months building the coolest (but mostly pointless) Fhem <-> POCO (Plain Ol' Code Object) mapper à la Fluent nHibernate, using all sorts of stuff I'd not really dug into before, such as generics, consuming lambda expressions, Moq-based isolation testing, fluent APIs, etc.

But so far, as much fun as it's been, I've got squat to show for it.  I'm as annoyed as anyone, I've been boasting about having this nifty central heating control thing, and when anyone asks about it up comes a Putty console, and suddenly it all seems just lame.  Plus it's pretty clear that at this rate, as soon as I have anything useful out the door, I'll be basking in a freak British summer heatwave, with central heating concerns a distant memory.

I've decided the way forward is to start with a clean slate and what I hope to be a cleaner methodology.


Permalink | Comments (0)

Mocking Frameworks - Rhino Mocks vs Moq

This discussion has been had many times, by people far more qualified to comment than myself, but nonetheless, here're my thoughts.

The Story So Far...

I've been programming with unit tests for probably a year now, and as I get opportunities to write code from scratch (I do a huge amount of bug fixes and configuration work it seems!) I'm finding I can get more and more value from them.

About 2 months ago I started playing with the Rhino Mocks mocking framework, so that I can test my code without dependencies slowing down my tests or making them brittle, and I was totally blown away at how much easier my tests became.  The ability to mock objects without having to actually create the mock, and the ease with which the mock objects can be configured, is pretty astonishing when you first see it!

However last week a colleague of mine turns out to have been playing with another well known mocking framework, Moq, so I figured it would be worth looking at the two side-by-side before I pick one for use in this project.


Permalink | Comments (0)