Pedal Board

I got a little bit of money for Christmas this year and decided to buy a new tuner pedal (I got the TC Electronics Polytune Mini).  I decided to use this opportunity to make a change to my pedal board that I've wanted to do for the past 2 years.

My pedal board is based off this case:

And has a false floor covered in carpet:

But before today the lid was always attached which wasn't too bad but made it a little unwieldy when opened.  I've always wanted to remove the lid and attach it with more suitcase clips but never got around to it.  Given I've got time off at the moment I though I'd give it a go.  I bought 4 clips from Bunnings at $6.50 each and proceeded to drill holes and attach them.  This was easy for the part that was attached to the board as I could use long self tappers and they'd be hidden under the false floor.  The lid part I had to attach with the included split pins and work out a way of using a g-clamp and some screwdriver bits to get the split pins split enough.  The whole thing took 3 hours to complete mainly because of this and because I took my time at the start planning.

This is what the lid looks like now:

And here is a close up of the clip:

This is what it looks like with pedals:

I am quite happy with how it turned out and I finally have the pedal board I've always dreamed about!  For more information and more pictures see my gallery below.

Hard Code your Tests

So I was thinking about code reuse and testing and what the actual goal is from testing and came to the realisation that if you are testing for a certain value then you should hard code that in your test.  Let me give you a small example.

Say you have a timed dialog, ConnectionError and the timeout on this dialog is 5 seconds.  So you write a test that ensures this dialog times out in 5 seconds and all is good.  Now say during the course of work other dialogs are created and you decide that they are all of the type 'InformationDialog' and shall all have a timeout of 5 seconds.  Your test still passes and all is good.  Now at this point it might be tempting to go in and refactor the ConnectionError tests so that it doesn't test for a timeout of 5 seconds, but for a timeout of InformationDialog.Timeout.  This would seem logical as the ConnectionError is an InformationDialog.  I suggest not doing that, and here is why.  If you now go and change the InformationDialog.Timeout to 7.56 seconds the test will still pass.  But...

By the test passing you have missed that you have potentially changed a business requirement.  By the test passing you have missed the fact that your change in one area has affected something potentially unrelated.  I thought tests were there to help show when you change something and it has an unintentional side effect.  By the test passing you miss the conversation 'Is it important for the ConnectionError dialog to have a timeout of 5 seconds?  It also brings about another interesting point, tests should not be resilient to change.  In this case a good factoring has meant that even though you changed something the tests still pass, which is not something you want.  You do not want tests to be resilient to change, in fact you want them to break as soon as possible to alert you to the fact that something has changed.  Now I know you might be thinking that by hard coding tests and making them not easy to change will result in more time maintaining them, and you are potentially correct.  But I would argue that anything that is testing a business requirement should be, so that you 'think' about what you are doing before you act.  Couple that with making classes simple, and with less dependencies and the overhead will be minimal.