Dont Write Tests The Hidden Cost Of Tdd
I’ve been following the TDD/testing debate with some interest; I work at an early-stage payments startup called GoCardless where we test religiously. We’re not dogmatic about whether the tests come first or not, but code doesn’t get deployed without full unit & acceptance tests. It’s saved our skins on more than one occasion
I wanted to explore the benefits of testing and suggest some situations in which <heresy>testing may be counterproductive</heresy>
Testing - The Good Bits
When you’re working as part of a team on a large codebase, comprehensive testing is invaluable. If you measure development velocity on a company-wide basis over the medium-long term, testing provides clear benefits.
Engineers working on one part of the codebase don’t have to worry about their changes having unanticipated knock-on effects in another area. A good mix of unit tests and acceptance tests means that you can write & deploy code quickly, without a lengthly QA process.
When stuff does break, unit tests allow you to identify the individual component that’s causing problems. It’s fantastic - at GoCardless, no code goes into production without comprehensive testing & peer code review.
(If that sounds like a place you’d like to work, we’re hiring!)
Testing slows down rapid prototyping
Having said that, there are situations when comprehensive testing just isn’t the right solution. I’m not talking about whether tests should come before (TDD) or after writing code - there are situations where it might be beneficial to write no tests at all.
The particular situation I have in mind is the ultra early-stage startup struggling to find traction. The number one priority in this situation is not to write beautiful code or solve hard technical problems in innovative ways; it’s to work out what people people want. You do this by iterating quickly & launching early - just as it’s often possible to fake a much more sophisticated or elegant solution by doing stuff manually, it’s also possible to write quick, scrappy code that works just about well enough.
You’ll accumulate buckets of technical debt, but it’s generally ok. If you don’t find traction or “product-market-fit”, you declare bankruptcy on that technical debt and just move on to the next iteration.
Once you’ve found traction, you’ll likely need to re-write your codebase, but that’s ok as well. At this point, you’ll have a much clearer idea of what the product actually does, so writing specs should be much simpler.
As an addendum, I think this conundrum is one reason why outsourcing early-stage tech development is such a terrible idea - any decent web development shop will generally insist on writing comprehensive test suites, and they’ll react badly if the job spec changes dramatically every 2 weeks. But that’s sort of necessary when you’re writing code for an early-stage startup.