I almost didn’t write this article. Ideally, we would live in a world where programmers could simply write as many tests as they need without feeling like they have to justify it to others. Even so, it is a question I hear quite frequently.
I don’t usually have bosses anymore. I work mostly on a contract basis, so I tend to work with clients and lead developers. That’s very different.
With clients, you don’t even need to mention the tests. You just bundle them into the features. If it takes you four hours to code a feature, you just add on two or three more hours to write a few tests. If your estimate reflects the time it takes to write the code and the tests, you’re golden.
It’s a little different when working with a lead developer, but again the cards are in your favor. Lead developers know what unit testing is and almost always approve of it to some degree. You won’t run into any problems there.
So now, onto this mythical boss figure who needs convincing. How do you get that person on board?
I had boss a while back, and I failed miserably at convincing him to let me write tests. I learned some pretty big lessons from that experience, namely a litany of things not to do.
Epic Fail #1: Mention all the extra code you will need to write.
I once very foolishly made a point of saying that if we want to guarantee our app will be bug free, we will need to write twice as much code. You can imagine how such a statement would be perceived.
Was I right? Kinda. Back then, I knew tests were pretty important, and I was definitely seeing an increase in the quality of my work as a result. However, I was too dogmatic about it. I thought we needed to have 100% test case coverage before shipping any product.
Here’s a fun fact. The business world doesn’t work that way. The business world is all about arbitrary timelines and minimum viable products.
Again, no judgment. That’s just my experience. Most of the time, it makes much more sense to put out an imperfect product than to agonize over every tiny detail. You’ll either get some great feedback, or you’ll soon discover that people just aren’t interested in your product.
In this sort of situation, the last thing anyone wants to hear is, “Hey Bill, we need to double the projected timeline.”
Bill asks why, and you say “We need to write twice as much code to ensure there is adequate unit test coverage.”
Then Bill says, “Oh, let’s just not do the tests.”
No manager will ever want to hear “twice as much code.” Never ever say that. There is simply no Universe in which that sounds like a good thing.
Even if you understand that test code is less complicated than production code, which it tends to be, the prospect of writing “extra code” is still going to be perceived as a huge maintenance burden. Your manager’s immediate reaction will be to think it’s not necessary.
Epic Fail #2: Go on a crusade and start bringing everything under test right this very moment.
Nothing says “I’m fascist about tests,” quite like running amok in someone else’s code without discussing it first. If the code is working just fine, leave it the hell alone.
Tis’ the curse of an orderly mind. When we look at other peoples’ code, the impulse is to clean it up and make it more like our own. Sometimes this helps, but if you aren’t working on a new feature, you’re probably wasting your company’s time.
It’s much better to wait until a new feature requires you to demolish the old infrastructure. If you find a good reason to add tests for that feature, go ahead and add them then. Otherwise, don’t get so zealous so quickly.
Epic Fail #3: Blame every failure on the app’s lack of tests.
I get it. You want to write tests. But not every problem stems from a lack of tests. Most bugs result from a lack of planning. People simply didn’t take the time to think about what’s supposed to happen when the user triggers some edge case.
It definitely helps to have tests, but how you can test against something that isn’t in the formal requirement definition?
Things are going to go wrong for all kinds of reasons. If you keep harping on the lack of unit tests, it makes you seem like you care more about the tests than you care about solving the problem at hand.
The problem in front of you is more important. If unit tests help you solve it, write tests. If tests don’t help, don’t write tests.
Epic Fail #4: Stop doing manual tests.
Dogmatic TDD sometimes leads people to think they no longer need to do any more manual testing. That would be nice, wouldn’t it? But if there’s one thing that’s sure to sour your boss on unit tests, it’s a bug that wasn’t surfaced because you thought you didn’t need to do any more manual tests.
Always make sure you keep doing some amount of manual testing. There’s a good chance you’ll find a few bugs your tests didn’t catch.
Don’t make me think
I remember this one time I went to Chipotle. As they wrapped my burrito, the tortilla began to tear. No biggie. I really don’t care about that sort of stuff. People mess up small things like that all the time.
But instead of simply re-wrapping the burrito, they gave me a choice. Did I want the torn burrito, or did I want them to wrap it again?
“Um… I don’t know? Wrap it again, I suppose? Can I ask why I should be involved in that decision?”
I can guarantee the CEO of Chipotle wouldn’t be too thrilled to hear about employees asking customers if they want to eat a torn burrito. Chipotle has a certain quality standard it adheres to. Every burrito should simply hit the standard.
The same goes with your code. You shouldn’t ask to write unit tests for the same reason you shouldn’t ask to do a good job. Your clients and customers expect a certain standard of quality. As long as they give you enough time to deliver that standard, you shouldn’t need to ask any more questions.
So instead of getting into the weeds and asking about tests, just put the extra time into your estimates. Don’t go overboard, but definitely factor it in.
Trust builds autonomy. If your boss already trusts you, there’s no need to ask weird questions that might jeopardize the trust. If you don’t already have trust, perfect test coverage isn’t going to give you it.
The zeal for 100% test coverage can actually harm your business relationships.
Managers don’t think like you and I. They don’t care about absolute perfection. They just want to ship the damn thing, even if there are a few problems left to iron out.
I’m not saying don’t fix those problems when you know they exist. Just understand that your primary job is to deliver “good enough” software, not tests.
That’s all for now. If you loved this story, hated it and wish to troll me endlessly, or if you have your own unit test story to share, please recommend and follow.