Cover image by Isaac Smith on Unsplash

In my last post I talked about code coverage and its usefulness as an educational milestone for any aspiring developer to conquer.

Achieving 100% code coverage will make you a better developer. Seriously.

Daniel Irvine 🏳️‍🌈 ・ Feb 11 ・ 3 min read

#javascript #webdev #testing #tdd

I finished the post by saying that experienced TDD practitioners have little need for code coverage because they will be hitting 100% coverage by the very nature of their development process.

But unfortunately for us, we have no good metric for measuring how effective we are with TDD.

Software design itself is fairly subjective, so that’s one reason why we don’t have a good measurement. None of us can agree.

If you’re a TDD practitioner, how do you know you’re any good?

The old “I don’t need code coverage because I do TDD” excuse

It’s been a long time since I bothered to use code coverage metrics as part of my regular development process. (To be clear, there are times when I do use code coverage--to verify coverage of a unit that I didn’t write, and to check how I‘m doing when I’m using test-after with legacy code.)

When I have clients ask me why I don’t bother with code coverage, I tell them I follow “strict” TDD so I don’t need it.

But it’s an excuse. I say this because people trust me that when I say it. They think it’s true, a fact. But of course it’s not. I say it because I’m lazy and code coverage it just one of those things that very rarely helps me in my day-to-day. And it’s mostly true.

But what happens if I’m having an off-day, or I’m in a rush?

What happens if I make accidental mistakes in my tests?

What keeps me honest?

More to the point, how do I know that I’m writing good tests, and how do I know I’m any good at software design in general?

I don’t really have the answer to that. There’s only one way I know that really helps: working with others.

Keeping yourself honest by working with others

Pairing, and mobbing, helps you follow the TDD cycle religiously. It goes some way to stop you slipping up, cutting corners, making mistakes. Plus, it’ll improve your software design.

It can help with building the right thing, too. When you mob you might have the opportunity to include a QA person within the mob. With any luck, they’ll have some input on what requirements you may be missing.

Then, as the mob signs-off work, everyone involved should be able to say they they believe they tested everything to the best of their ability.

If you have any of your own ideas about how to measure your TDD skills, I’d love to hear them.