Thread by @GeePawHill

Coaching Pro-Tip: When the developers act like testing the code is a time-wasting checkbox that costs a great deal and rewards very little, they are usually right, and one has to find out why, and tackle that, before pressing them to test more.

In test-after shops, it's quite common to set a test goal, usually but not always expressed in terms of coverage numbers. Once this is done, the org begins to press the developers to meet that goal.

My experience is that this kind of pressure backfires way more often than it succeeds.

When the boss tells someone to do something, they will usually do it. If they find the something beneficial, they will quickly learn to do it well. If they find the something markedly unpleasant, they will quickly learn to do it just enough to check it off the list.

If a developer hasn't learned how to write tests well, it's often because they haven't learned to write *any* code well. What they need isn't a checkbox, it's mentoring.

So when I see the signs in a test-after shop that writing tests is considered a chore, I go study some of those tests, up *close* I study them. And what I usually find is that the tests are either expensive, useless, or most commonly, both.

Primitive obsession in the data setup, lots of automocking that renders the test empty, bad names because scope is too large. These are the things I usually see.

Notice: every one of those things is not actually a test code problem, it's a shipping code problem. The test code is that way because the shipping code is that way.

So if the developers are signalling you that testing is an unpleasant chore, you know what? Believe them, find out why, and make fixing that your target, not a coverage number.