Tag: TDD

Testing, Testing…

I’ve recently been interested to see a couple of examples where the concepts of test driven development and regression testing were clearly not applied, or at least not applied as they should have been.

The first example was FaceTime on my old iPod Touch. Having worked perfectly happily for years, communicating with an identical device in the UK, it suddenly started failing, and for a while I was reduced to using the much flakier Skype. As you do, I stared surfing the web for answers to the problem. I soon found a growing number of people interacting on various on-line forums complaining about a similar issue. Clearly, the common denominator seemed to be a regression caused by a recent upgrade to the iOS operating system on iPod Touch 4th generation. Interestingly, the response from Apple, if the experiences of those on the forums were anything to go by, seemed to be one of total disinterest. However, a few weeks later, Apple quietly released the following fix for a problem that had affected ‘some users’ (i.e. many):

http://support.apple.com/kb/DL1701

Now I know, from painful experience, how hard it is to test for this type of fault, but Apple should have had regression tests in place for changes that might affect popular standard apps like FaceTime.

The other interesting example was this one, about LG televisions sending personal data back to the company, even when a privacy setting had been turned on:

http://doctorbeet.blogspot.co.uk/2013/11/lg-smart-tvs-logging-usb-filenames-and.html

Now you would expect, if this software had been test driven, that a test would have been written that ensured that activating the privacy setting meant that data could not be sent. Instead, data was still sent, along with an indication that the privacy setting was turned on. Either that wasn’t tested at all, or it was driven by a stupid test. The alternative interpretation, that LG wants your data whether you like it or not is, I’m sure, not the case.

These two examples are instructive because they emphasize how important it is to (a) drive your designs with unit tests and (b) avoid the entropy of your software with regression tests.

 

 

Global Day of Coderetreat

gdcr_ad_textGlobal Day of Coderetreat

Last weekend I participated in the 2013 Global Day of Coderetreat, joining the session running at the Xero offices in Wellington, New Zealand. Along with 2,000+ other software developers across 165 locations on all continents, I spent the day honing my software craftsmanship, pair programming with other developers, using test driven development (TDD), and working within a range of changing and challenging design constraints. A coderetreat is an opportunity to look at the same programming problem (typically Conway’s Game of Life) from multiple perspectives, without the pressure to create a finished product but using the opportunity to reflect on how we build software. I would recommend that all software developers, at whatever level of skill and experience, take a look at the coderetreat.org web site and keep a look out for upcoming coderetreats in their local area. If you can’t find one, why not run one yourself? All the information you need is on the web site. The only people who won’t gain anything from it are those who just want to show other people how great they (think they) are. Fortunately, these people are a tiny minority of the software development community. Most of us will embrace the opportunity to challenge themselves and learn from others, in a day of coding that is surprisingly enjoyable.