This is my personal blog. The views expressed on these pages are mine alone and not those of my employer.

Tuesday, 25 November 2014

MSTest Breaking Changes and the Legacy Lifesaver

Today I encountered an issue with a group of unit tests that were failing on the build server but running fine on my development machine.

The commonality between these tests is they were all making use of an attribute that extended ExceptionBaseAttribute defined in the UnitTesting namespace.  This extension compared the exception message, rather than just the exception type as provided by the vanilla attributes.

My development machine was running VS 2013 the build server VS 2012. After a bit of digging it was clear I was looking at a breaking change in the VS 2012 test runner.

So what could I do about it?
  • Upgrade the build server? Not viable
  • Ignore the tests? Plain stupid
  • Toggle exception attributes with preprocessor directives? Hacky

There was a fourth option.  MSTest legacy mode.

To enable it I first had to create a solution level file with a .runsettings extension, of which I placed the following contents:

This was then checked in and referenced in the build definition under Automated Tests -> Test Source -> Run Settings:

From this point onwards all tests were running as green as ever.

Perhaps this helped you?  Have you experienced any MSTest breaking changes?

Saturday, 8 November 2014

Solving the Software Estimation Enigma

Software developers are pants at estimation
M. Edmondson

There, I said it.  You and I both know it. It's one of the hardest tasks we face as a software developer. But guess what, there is a way that's worked for me and it's backed up by the likes of 'uncle' Bob and others.

First and foremost it's important to understand an estimate is not a single number. An estimate is a distribution. This means your estimate will be a range of numbers in which the task will complete. Think 6 hours, plus or minus 2.

The reason for this is that you'll always have to make assumptions at some level.  A range takes into account unknowns such as a web service being down, or finding you need to modify a method which uses a wretched spaghetti of reference values or [add your developer woe here].

So how do you create such a estimate? First break down the problem into the smallest feasible chunks of work.  Try to get as granular as you can, but don't worry too much if you're struggling.

Then decide the following 3 timings to complete the task:
  • b = best case
  • w = worst case
  • m = most likely case (i.e.what your estimate would've been before you read this)
b and m are complete edge cases, a one in a lifetime event.  For the maths to work these must have less than 1% chance of actually occurring.

Then simply plug them into the following equation to get the first part:

e = (b + 4m + w) / 6

v = (w - b) / 6
These two sets of magical numbers let you know:
  • e, how long the task will take
  • v, the variation on this number
You therefore tell the project manager / business the task will take:
"e plus or minus v"
This has rewarded me with surprising accuracy whilst also providing the benefit of communicating your certainty (v).

Do you agree?  How do you solve your estimation enigma?