I little while ago I had a discussion with a respected colleague who took a different view to me on unit tests. He proposed that writing tests at the unit level means more code to write and maintain, whereas testing functionality in bigger blocks yields the same benefits with less overhead, plus unit tests don’t test how code behaves when the blocks are plugged together. It feels like this approach makes TDD impractical, but does that matter? As long as everything is tested we’re good, aren’t we?
We write end-to-end tests and integration tests anyway. Maybe we need to think about the scope of our integration tests, but do we really need 100’s or 1,000’s of unit tests too?
My opening gambit on the debate is that I like unit testing, and I like TDD. Yes, these practices lead me to write different code than I would otherwise, not least because I tend to end up with more and smaller classes. But, along the way, this enforces testability by default and encourages things like SRP (the ‘S’ in SOLID). These are good things. Also, well named, well thought out unit tests document the intent of your code and that’s good too.
Maybe my TDD inspired code is better? Furthermore, I like the short feedback loops of TDD and I like tests that clearly identify the point of failure.
To sanity check that I’m not just a decade behind the curve I asked Gemini, Copilot and ChatGPT if unit testing was dead. Their consensus was that it’s not.
But, my colleague is not alone, he’s part of a not insignificant crowd. My colleague is a respected person, so are they all, all respected people. With that in mind I’m working on a .Net 9 project of my own and I’ll favour my colleague’s approach and see how I get on.
Personally, I think the answer to the question in the title is more nuanced than a straight ‘yes’ or ‘no’. When I understand that nuance, I’ll post on it again.
I’d welcome any views that others want to share. If you want food for thought here’s a 10-year-old article by David Heinemeier Hansson (the creator of Ruby on Rails).