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

Flashing a CUL device for use with FHEM - Thrilling stuff!

Hi all,

Bad things happening tonight - I've just succeeded in (almost) killing my CUL USB device, for the second time, meaning my FHEM server has been temporarily unable to talk to any of my FHT hardware.  Fortunately the next day I managed to rescue the situation, so here's two posts in one - the horrible "I've broken it!" moment, and the jubilant "It's fixed!" moment.


Categories: FHEM
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)