Do we all agree yet?
Do we all agree yet?
There are three camps I have found around testing.
The ‘tests are necessary’ camp. I don’t know about you but I am a card carrying member of this camp. To be a professional software developer I think writing tests is necessary.
The ‘I’m not writing a real app’ people. When writing a script to get a one off ops task done then it would be a waste of time to write automated tests, if it is easier to figure out if it worked manually. I have no problem with this one. Although I am surprised by how often one off hack ends up in production for years.
Finally, there is the ‘rock star developer’ who thinks testing will only slow them down. They are quite often happy for other, normally less senior, developers to write tests for their code. Where any bugs found can be dealt with later but should not count as real development work as the implementation is already ‘done’. I find this type of attitude more of a problem than the lack of testing. You can get business value quickly, and it can even provide value for years, with this attitude towards testing. I’ve worked on apps that were critical to the business and survived in production for years with no tests at all. But these apps are unmaintainable. They are very hard to change, either to apply bug fixes or even just to keep them up to date on the latest hardware or kernel version or app engine version. This stores up risk and costs for the business which at some point must be addressed. If you don’t intend your application, or the company you work for to be around in two years, because it will have failed, or you plan to be acquired and be out of there, then this extended prototyping approach may be a path open to you. I would still want to think very carefully about this approach because code has a habit of sticking around much longer than you thought it would. It also does not benefit from any of the advantages of TDD. But be aware, that if your company is successful and someone needs to maintain this code in the future then the company is going to pay a high price for your decision.
All of this was meant to be a rebuttal to the obvious arguments that I have heard over and over again about why this team is special, why I am a better programmer than you have met before, why my application will be fine without tests. But really the best reason to write tests is that TDD is a better way of writing software and you get all the tests as part of that. Testing first allows you keep on track and only build what you need, it concentrates the mind. Writing tests before the implementation guides your design to be easily testable, but also to be cleaner. With TDD it is hard to get low test coverage and so future developers, including future you, will have the confidence in their changes by just running the test suite and seeing green. The pull to move faster, that this time is different, that it’s too hard to test this thing is strong. TDDing is the professional way to write software to last.