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.

More...

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.

More...

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.

More...