It was with some disbelief that I sat through Cal Henderson’s otherwise highly entertaining (and to be recommended) Building Flickr Workshop, to hear that automated testing didn’t feature highly in their list of priorities (as an interesting aside, Cal also considers object oriented programming to be ‘insane’, which all ‘sane’ code existing in the space between one-giant-function programing and OO). “Testing web applications” Cal said, “is hard”. This is a common misconception. Like any type of application, if you structure it for testability, testing is easy. And if you invest in testing tools written specifically for testing web applications (FIT and FITnesse, Selenium are good examples) even those applications written without testing in mind have no excuse for going without.
But with Flickr being such a high profile and successful application I assumed there would be a more mature approach towards automated testing. Is this laissez faire approach to automated testing common?
Lets look at this another way. If you don’t have automated tests, you either have to test manually (which means longer time to release) or you don’t test. If you are in the business of delivering quality products, it probably means you do end up performing lots of manual tests which could otherwise be done quickly, automatically and even if you want on every checkin.
The architecture of the web makes it idea for an agile release early, release often process. With the web, the only destination environment you have to worry about is your server and the client’s browsers. Pushing out a release really can be as simple as the one-click deployment Flickr uses. With a mature testing framework, releasing directly to your user can be managed multiple times a day if required.
Testing might not seem like fun – but once you realise it means you can release cool functionality to your users more often, and you’ll spend less of your time fixing bugs, perhaps we can all start to love writing tests just that little bit more.