If life were a game...

We had a discussion at work after watching the excellent Kelvin Henney talk about good unit tests . And it helped me clarify the many roles tests play and why people get a habit of complaining about their tests getting in the way. So here is the four categories a test is trying to balance: Requirements Regression Documentation Refactoring guide Most test today are written as requirements . And this is a huge improvement over the past when we'd write tests later and try and get code coverage. Those 'later' tests are useless. The requirement tests happen for high level acceptance tests and in low level TDD too. Your test defines a behaviour you want. Once your test passes you don't go back to change it at all beyond some obvious cleanups like code duplication. These tests allow rapid development and reliable progress. But they can hinder refactoring, provide poor feedback on failures for regression and may be too implementation focused to be readable. And eas...

I spend a lot of time working closely with programmers on the software testing process. Much of my career mission is to get more people embracing techniques like Test Driven Development. As I push more and more of the testing demands onto the developers I sometimes run into people who say they need a tester for "independent testing". It's a concept I'm familiar with from early days in my career. A tester can look at the system and requirements with fresh eyes and find all those cases the programmer didn't consider. If the programmer does all the testing they'll be too tempted to just test the cases they know the code is handling and not discover any new areas where bugs may be hiding. The problem I have with this idea is I never was that type of programmer. As a programmer if I didn't test something it was purely out of laziness and arrogance. I'm a big supporter of Larry Wall's  three great virtues of a programmer. A lazy programmer will d...