Writing Tests doesn't have to be extra work

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.

Want to build your desktop, mobile or web applications with high-performance controls? Download Ultimate Free trial today or contact us and see what it can do for you.