Stories about Software


Writing Tests Doesn’t Have to Be Extra Work

Editorial Note: I originally wrote this post for the Infragistics blog.  Check out the original here, at their site.  If you like this post, please give them some love over there and go check out the original and some of the other posts.

Writing automated tests is sort of like the kale of the software development community.  With the exception of a few outlying “get off my lawn” types, there’s near-universal agreement that it’s “the right thing.”  And that leaves a few different camps of people.

The equivalent of fast food eating carnivores say, “yeah, that’s something that we ought to do, but it’s not for me.”  The equivalent of health-conscious folks plagued by cravings say “we do our best to write tests, but sometimes we just get too busy and we can’t.”  And then, finally, the equivalent of the health nut says, “I write tests all the time and can’t imagine life any other way.”  A lot of people in the first two camps probably don’t believe this statement.  I can understand that, myself, because it’s hard to imagine passing up fried chicken for a kale salad in a universe where calories and cholesterol don’t count.


And yet, I am that ‘health nut’ when it comes to automated testing.  I practice test driven development (TDD) and find that it saves me time and makes me more productive on the projects I work.

It is because of that tendency that I’d like to address a common sentiment that I hear in the industry.  I suspect you’ve heard variants of these statements before.

  • “We started out writing some tests, but we got behind schedule and had to hurry, so we stopped.”
  • “TDD doesn’t make sense in the early phase of this project because we’re just prototyping.”
  • “We didn’t want to write any tests because there’s a chance that this code might get thrown out and we’d just be writing twice as much code.”

The common thread here is the idea that writing the automated tests is, when the rubber meets the road, a bonus.  In the world of software development, the core activity is writing the executable source code and deploying it, and anything else is, strictly speaking, expendable.  You don’t truly need to write documentation, generate automated tests, go through QA, update the project milestones in a Gantt chart, etc.  All of these things are kale in the world of food — you just need to eat any kind of food, but you’ll eat kale if you’re in the mood and have time to go to the grocery store, and… etc.

But if you’ve truly internalized TDD as not just “the right thing” but rather “the thing that makes you productive,” you simply don’t look at the world this way.  You’re now a kale eater that loves kale.  You write tests first in the same way that you use your favorite IDE/editor with all of your customized shortcuts and syntax highlighting arranged just so — because you’re better that way.  Writing and leaning on your tests becomes as integral to your development as compiling the code.  And in that context, re-imagine the preceding statements.

  • “We started out compiling the code, but we got behind schedule and had to hurry, so we stopped.”
  • “Compiling doesn’t make sense in the early phase of this project because we’re just prototyping.”
  • “We didn’t want to compile because there’s a chance that this code might get thrown out and we’d just be wasting time compiling.”

That sounds absurd, clearly.  But why does it sound absurd?  Well, it’s because periodically making sure that the code builds and that you’re not piling up syntax errors is just what you do.  Asking you NOT to do it would throw you off your game, and you’d be perplexed that someone would think to demand this of you.

That’s how I feel when I hear such statements about automated tests and imagine applying them to my own approach.  It just wouldn’t work very well.  And, if you’re making statements like this, it’s an indicator that you’re in the, “I’m going to try to eat kale, but when I’ve had a long day, I just want a burger and a beer and for you to leave me alone” camp.  You have not internalized automated testing to the point where it’s indispensable to you.

And, you know what?  That’s okay.

Getting to that point of internalization is not easy, and it requires a lot of practice.  And it may even be that it’s just not how you want to do things.  I’m personally of the opinion that internalizing it has the potential to make you more effective but, clearly, I’m not omniscient, and I can’t know that.

And if you’re not at that point, then you’re right when you make statements about deviating from tests when the pressure is on.  If an automated test suite truly is a bonus above and beyond software delivery in your world, then it is absolutely rational to abandon it when the pressure is on and deadlines have to be met.  I understand that.

But in exchange, I’d ask you to understand and acknowledge one thing: automated tests aren’t a “bonus” for everyone, and they don’t have to be for you.

Newest Most Voted
Inline Feedbacks
View all comments
Helton Moraes
Helton Moraes
8 years ago

The comparison between “writing” tests vs “running” the build is unfair. I believe the emphasis in *writing* the tests makes it sound more of a chore than it really is. Now compiling is a different thing, a bit like watching consecutive runs of a slot machine. And of course you have to write code for that. I think a better emphasis would be *RUNNING* some tests (which you incidentally would have to write anyway), because the continuous cycle of instant gratification of seeing a green bar being spit out by the machine as you go is more than enough to… Read more »

Erik Dietrich
8 years ago
Reply to  Helton Moraes

I wasn’t really intending to go for a comparison, per se. I was hoping to say, “you know how you compile the code pretty regularly? Writing (and running) tests is that way for me. It’d be weird not to do it.”