I’ve worked projects with good testing cultures and those with none, and I’ll say without hesitation a good testing culture is well worth the effort, and the longer you put off testing the higher the cost it is to incorporate and the less likely you are to reap it’s rewards fully. Consistent testing will:
- Test your every assumption you make as you code
- Force your code to be cleaner and compartmentalized
- Document in the purest form how you expect your code to be used
- Fix problems before you have to resort to the debugger
- Insure incremental changes can be made quickly and with confidence
- Allow for safe code cleaning and dependency migrations
If you ignore these truths you end up with the opposite, code rot and technical debt that insure the entropy of project steadily increases.
So, am I advocating the early involvement of a QA team/process? No, because QA is already too late. If you depend on another team to test things after the fact you lose most of the benefits above.
Testing early means as early as possible. As you code, or if you follow Test Driven Development (TDD), then before you code.
The core tenant of TDD is to write the failing test first, and then code to get the test to pass. There’s a lot more to it, about how to best approach it, and how to get the most from it, but at its heart it’s that simple.
Do I use TDD? Yes, mostly. Even zealot TDD advocates acknowledge that there are times TDD isn’t appropriate, where you’re discovering the solutions by muddling around. But mostly it’s applicable. And too, at times I’ll be lazy, but I know what I’m sacrificing when I am. By and large, if the code is at all challenging and will be around for more than a few days, I lean on TDD as much as is realistic. Take a look at my open source stuff – my coverage is usually 70%+ out of the gate and 90%+ as the code settles out.
Who are the TDD luminaries I respect and follow? My favorite Martins: Robert Martin, Martin Fowler. They are great software engineering resources in general but for TDD you’ll want to start by watching one of Bob Martin’s keynotes or read Martin Fowler’s recent discussions on TDD.