Bit offtop, not debunking the content of this post though!
There were lots of brittle mocks. I think we even did mock out the Ruby equivalent of the HTTP client.
Every change would inevitably break tests (not functionality!) and developers were spending more than half their time wrestling with the test suite.
All of us could have used this article.
Please always strive to improve your practice. Commit things that aren’t perfect, but try to internalize best practices over time. Gradually raise your own code quality bar as you get better.
Learning from posts like the OP is super important if you don’t have a good senior Eng on your team. A group of smart juniors can easily code themselves into a hole of left to their own devices. I know this, because I did this.
Not sure if I’d have been smart enough to take my advice though. ;)
I find that this invariably happens because the team tries to test implementation at a very low level rather than behavior at a high level.
I blame an overemphasis on unit tests over integration testing (e.g. J B Rainsberger's inane rant) and tutorials that imply that, for example, if you build a class you have to have some tests for that class.
The other thing Juniors don't get is prototyping. I regularly build something quickly to get the problem set into my head. If it's good enough, I'll leave it. If it's got issues, I'll throw it away and start fresh now that I know what I'm solving. Juniors don't work fast enough or effective enough to do things like that without putting timelines at risk. Plus, they frequently want to do some cargo cult methodology of the week like TDD.
Are you saying you have to tell the developers not to test business logic, or that you have to fix the tests they write?
Test code should fail when an important underlying mechanism regresses. If it always fails on the next phase of the project because some hapless idiot needed to cover every line, the signal to noise ratio gets weaker and the purpose of the test code is lost.
Same goes for prototyping. I don't see much of a correlation between willingness to prototype and seniority, either.
Railing against code coverage is at this point just as dogma as insisting on it.
What I'm railing against is the idea that seniority is a prime indicator to the effective strategy parent comment insists on, which simply doesn't mirror my experiences. What I see is juniors picking up the habits of their superiors. They're learning this dogmatism from somewhere.
Willingness is one thing, but getting yelled at for learning and doing your best is another. I never treat my Juniors like that, and encourage a 75/25 working/improving split. Still, several frequently get anxiety about how long it's taking them to clear tickets.