Daniel Irvine 🏳️🌈Cover image by Oleg Laptev on Unsplash
TL;DR: If you’re a work on a team with people with less experience than you; if you’re a a team lead; if you’re a prolific tweeter; if you’re a book author or a thought leader: then people are listening to you and giving weight to the things you say. Please, please, please be careful of the message you’re putting out.
Your years of experience, learned pragmatism and understanding that what we do isn’t a binary of black and white is lost on novices.
And there are many more novices than there are experts.
This post is a follow on from this post, in which I found myself defending the notion of clean code:
To save any finger-pointing I’m going to put the debate about clean code aside and instead invent a blog post with dangerous messaging on a different topic and then disect it.
Imagine that the next section (in italics) is the beginning of a blog post posted somewhere on the web. We’ll discuss it afterwards.
Code coverage is completely useless
If you’re following “strict” TDD well, then you’ll naturally be at 100% coverage all of the time. So don’t waste time setting up code coverage as part of your CI build, instead invest time in your TDD technique.
This advice sounds emminently sensible to me. I’d probably give this post a heart ❤️ and a unicorn 🦄. In fact I very rarely use code coverage in my own work. I am indeed someone who follows “strict” TDD.
Then again, I’ve been around long enough to know there’s trade-offs in everything, and that code coverage is useful to a lot of people.
What about that word completely? Code coverage is completely useless? I can tell you that I only added completely in because I liked the alliteration. I didn’t add it in because I believe it to be true. It just sounded good.
Then again, I have the knowledge as author to know that I’m preferring a smart headline to the cold hard truth of the matter, which is that code coverage is not completely useless.
But it sounded good. What’s the harm?
The headline becomes ammunition
Imagine the blog post is being read by someone who is currently sitting on a lingering ticket in their backlog which is to set up code coverage on their CI system. This task hasn’t been done yet because no one wants to do it. It seems like a horrible task and everyone on the team knows their code coverage is going to suck, and they’re avoiding that judgement.
This article becomes ammunition and allows someone to successfully argue that code coverage is useless anyway, and what we really need is to start doing TDD.
That deflects attention away from the menial CI work; it also puts off action for even longer while the team gets lost in discussion about TDD; and then of course everyone gets stuck in inaction because TDD is a difficult culture to bring to a team.
It gives legitimacy to bad practice
Modern software is so complex that it’s very easy to fail with any particular technology. It’s even easier to blame the technology rather than yourself.
I see this all the time with testing technique, which is notoriously hard to do well. People always screw up before it gets better. It’s normal. If you don’t access to a good mentor/coach then you’ll probably get stuck. You can’t improve.
Once you’ve failed, to save face you have to blame the technique. So now comes all sorts of dangerous messaging from these people:
- Mocking is a code smell
- 100% code coverage isn’t worth the effort
- Unit tests are useless
and so on.
This legitimizes the fears of other developers who have struggled with the same concepts but are still trying, or have never tried but have only heard negative viewpoints.
It pulls the industry backwards
Any time you speak negatively of any practice, you are undoing the many laborious hours, days, weeks, months and even years of work that people have put into refining and promoting it.
If you think you can do better, then build on their work or build something new. Promote your own work. That way, you’re moving us all forward rather than back.
