Currently reading and liking It’s OK Not to Write Unit Tests (I wish I’d had this when I wrote What is “test-driven development for web applications”?)
Currently reading and liking It’s OK Not to Write Unit Tests (I wish I’d had this when I wrote What is “test-driven development for web applications”?)
New comments are no longer accepted, so if you want to get in touch, send me an email.
In my experience, I would sadly agree that “Unit tests tend to overspecify behavior—they test implementation details that don’t matter, rather than fixed contracts that do.”
My current opinion: unit tests are most useful when you’re going to reuse a small piece of code in several contexts: either in multiple projects, or in widely different applications within the same project.
This is especially true when there are many developers/projects/teams involved and the codebase continues to evolve. I feel much more comfortable using someone else’s component when there are tests I can run against that component. Inversely, I also feel more comfortable having someone else reuse a component I wrote if there are tests for that component.
When quickly developing a small application with a small team, I don’t always find it necessary to test everything, but I like to at least setup an empty skeleton for tests whenever a new component is created. This makes it easy to write regression tests the moment they’re needed. By the time we want to reuse the component in another context, there are often already a few tests written, so the bar to a more “complete” suite of tests is lower. What you end up with is a “just-in-time” suite of tests when you come to that point of wanting to reuse the code in another project or another context.
If it’s not clear, I don’t practice a lot of TDD. I find it useful in isolated cases on small components, but the cost of iteration speed is usually too high otherwise.