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