My Boss Won’t Let Me Write Unit Tests

I gave an in person talk at a conference pre-Covid on TDD/BDD. To my surprise, the room was overflowing with attendees. After the talk several people came up to speak with me. There was a lot of excitement about learning these techniques.

A couple of developers said “We really enjoyed your talk, but our management won’t let us write unit tests. They say it takes too much time.”

This was disturbing, as I am usually the one cracking the whip about creating more tests so that we can be confident in our code. Are there really people who call themselves managers out there that don’t want to see any tests?

I asked them if their boss looked over their shoulder while they were coding. “Learn TDD on your own time on your own side projects. Then start using it at work and show management how much faster it is.” Their answer was that their management looks at all of their code check ins and would object if they started “wasting time” on unit tests. I was a bit flippant and said “Find a new job.”

I probably could have handled that better. But I think that advice was pretty good. As a developer, especially a younger one, you can’t waste time with a bad manager.

I’ve been very fortunate in my career. I’ve only had one boss that I thought was really bad at what he did, and I got out of there pretty quickly. Nothing can make you more miserable at your job than a bad manager. My early managers were very good and saw it as their job to develop their employees. I haven’t had a technical manager in decades, so the idea of someone looking over my shoulder while I code is pretty foreign.

I worked in a company that was building unit tests in the late 1980s, so none of this has seemed new or revolutionary to me, it’s just how it’s done. Perhaps it was because we were building systems upon which people’s lives depended.

When I was first exposed to the Three Rules of TDD I had a giant “Aha!” moment. I had been doing Test First and Test After, but not TDD. I was sold on the benefits of having unit tests, but had not been exposed to the concept of letting the process actually drive the code.

Adopting TDD seemed like the most natural thing in the world.

Which is why I have a very difficult time understanding managers that are trying to prevent their developers from using TDD. And it’s even more gob smacking that in this day and age there are managers that are against the concept of unit tests.

Imagine if the way people learned to code was to follow TDD. Would anyone, having started that way, be able to be convinced that they should just dispense with tests and slam things into production because it’s faster that way?

We can make all the standard argument about how TDD is actually faster than “cowboy coding.” How your code is always never more than a few ctrl-Zs from being in a working state. How the code/debug cycle is responsible for more pain and misery than almost any other aspect of our jobs. I can go on for hours (and have) talking about the benefits of TDD.

But those arguments won’t work for someone that just doesn’t get it. How can writing twice as much code be faster? And if they aren’t willing to try it out and see for themselves, what is the answer?

Perhaps I was right. The real answer is “Find a new job.”