This is really a clash of two titans, both of whom I greatly admire -- Joel Spolsky (Joel on software) and Robert Martin (uncle Bob). I follow both of them for many years, their writings, on Twitter, podcasts and so on. Uncle Bob was not so happy about the discussion on Stackoverflow podcast #38 and he responded in kind.
- Unit testing is extremely important. Every minute that a developer spends writing a testing is well worth hundreds of minutes he would spend later in the maintenance phase. Having said that, if the concern is whether 100% code coverage is too much? Perhaps it is, determine what gives best bang for your buck and go with that. If the question is whether they are useful at all? Absolutely. Taking the same reason as cited in the podcast -- you have a large code base and now you need to either modify or add new features. Once you make the change:
- how do you know you are done? I run the unit tests that I wrote for the new functionality and pass them.
- more importantly, how do I know whether I broke any existing functionality? I run all the tests that I have (assuming I have decent code coverage) and make sure all the tests are passed.
- unit tests along with the acceptance tests, if run more often, can provide extremely useful information about any deviations from the requirements. Rapid feedback, isn't it one of the core principles of agile?
- You don't have to follow TDD to the tee, or any methodology for that matter. But the spirit of unit testing, in my opinion, is extremely important to know the health of your code.
- SOLID principles, as Uncle Bob said, are engineering principles. These principles guide you in building the software that is flexible, maintainable and reusable. This is even more important in agile environments where you develop software in tiny increments.
- Enough emphasis must be given to code hygiene. With out that, it is just a matter of time that the system gets polluted, and not sure how you can keep the customer happy for long. I agree that the focus should be on the customer and just don't architect or refactor just for the sake of it. Focusing on the customer means -- designing flexible, extensible architecture (using design principles) so that you spend less time in constant-maintenance mode.
- Another common argument against writing tests is time to market. Goal is to get the software out as quickly into the market as possible, fair enough, but at what cost? As software craftsmen we need to pledge for not shipping shit (must read).
I repeat, I have great regard and respect to both the individuals, and hope Joel can elaborate on some of the points that are discussed in his future podcasts and clear the air.