As I'm doing more and more work with unit tests, I'm beginning to have some pretty unconventional ideas around the way we organise our test code and production code. My latest thoughts? I'm seriously considering putting all of my unit tests in my production projects and wrapping them in compiler conditionals so they're not included in release assemblies.

These aren't the worst suggestions I've heard - some people are even advocating including your unit tests in your production classes, just tagged at the bottom, I'm not sure I'm quite that far gone, but I'm getting there.

More...

Yesterday (and the day before, and the day before that) I spent some time try to get my Subversion install to send a message to Twitter when I commit some code.  Yes, I know it's a fairly pointless feature, but it started off as a bit of fun, which really I should have cut and run after the first hour of non-progress.  But I'm a stubborn kinda guy, so I ploughed on, and eventually got it to work.  Here's (some) of the story.

If you want to know how I got it to work, skip straight to step 4.

More...

Hi all,

Today I'd like to share my experience with the builder pattern, and how it can radically improve the brevity and readability of your tests. Don't you just hate unit tests that have a whacking big "Arrange" section, one that fills up your whole monitor screen? While it's not a magic bullet, the Builder pattern can help with this.

Simply put, the Builder pattern involves creating static classes with static methods designed to new-up instances of your business-entity classes, populated with common and typical data. Used with some extension method goodness, we'll also see how easy it is to create builder classes using nice fluent interfaces.

More...

Hi all,

A short one - and it's actually a tip I've picked up from a co-ninja in the office (much kudos due to @datoon83). When doing some work with unit tests, we've discovered an anti-pattern we've applied throughout our application, which is to hard-code messages into our source code.

The simple lesson - don't use string literals in your application code, use Resource files instead! There are plenty of examples where we've done it, things like exception descriptions, audit  notes, user confirmation messages, etc.

More...

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.

More...

Hi all,

A bit of a departure from the norm with this post, in that there's no coding involved!  Some background story to start.  A couple of years back I acquired a second hand HP Compaq TC1100 tablet PC. First off, this tablet is a proper thing of beauty - okay it's a bit chunky, but it's certainly aged well.  My plans were to fit it in my kitchen so that I could stream video recipes, TV (via the excellent DVBViewer), online radio, etc.  The only problem I had - where to fit it?  I don't want it just lying around on the worktop, it'll get covered in oil, crumbs, all sorts. And how exactly do you stick a computer to a wall!?

More...

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 https://github.com/sawilde/opencover), 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!).

More...

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.

More...

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