I'd say that it's also important once the team gets beyond a certain size; codebase and team size tend to scale together, of course, but not always. The value

I'd say that it's also important once the team gets beyond a certain size; codebase and team size tend to scale together, of course, but not always. The value of tests in catching regressions in code you didn't write, didn't realize was there, and don't understand is immense. It's one kind of difficult to not introduce regressions in 100k lines of code that you were deeply involved with; it's a whole different deal to walk into 100k lines of someone else's code and try to change it without breaking anything. Unit testing is like vaccination: it's good for me that I'm vaccinated against smallpox, but it's also really good for you that I won't be getting sick and giving it to you, and your ability to avoid vaccination (or testing) and still function is often directly correlated to how well everyone else is vaccinated (or how well they've tested their code so you know when you're breaking it). Those don't always have to be unit tests in the strictest sense, so you could perhaps argue that a test that breaks as a result of unrelated changes isn't really a "unit" test because it wasn't properly isolated, but I really hate those sorts of language arguments. I'll call something a "unit" test if it's not an "end-to-end" test, even if I didn't mock or stub out every possible dependency. And it certainly sounds like the author of this post is arguing against unit tests in that sense rather than in the stricter sense.