The Problem: Resource Limits

So you just bought your shiny new piece of the hottest tech – maybe a new phone or a cool new smart watch – and you are itching to unlock all of the new bells and whistles. You power it up, a few seconds feels like years waiting on this black screen… 10 minutes… 15… will it ever turn on? Should it be doing this out of the box? Did I really pay all of this money for something that doesn’t work?! Didn’t anyone test this thing?!?!

Sure, someone, somewhere tested it. Well, they powered up in the emulator on their test environment – isn’t that good enough? “I didn’t have time to make sure it worked on the device, but it worked in my environment so it should work in real life, right?” Sadly, I think most of us have had a similar issue sometime in our lives – and we love to blame the whole company, or even the IT guy we spent hours complaining to until he finally told us to send it in so they can have a look, for a problem that stems from nothing more than a limit on resources.

This limit can be shown by the Fast-Good-Cheap triangle for project planning. Pick two goals, and the third suffers. You can have a good, well-tested product by your deadline, but it will cost you. Don’t want to pay? Well, you can have it by your deadline, but it won’t be thoroughly tested. Want it cheaper but well tested? That’s going to take another couple of months.

The Solution: Unit Testing

There is a way to curb the “good” side of the triangle at least a little, and that is with Unit Testing. Unit testing has become quite the buzzword over the past several years. Still, developers know they should be writing unit tests, but they don’t have the time for it. And as long as I test it, that’s good enough right? Yes – and… no. To explore this question we should first define what a unit test is.

What is a Unit Test?

A unit test is exactly what it sounds like. It takes a system’s smallest indivisible parts (units) and tests them individually, guaranteeing each piece of software works alone and by itself. Each unit test itself should be completely independent of the other pieces of software it is not testing, and should be scheduled to run on a timely basis to notify when new code does not work.

Back to the Solution

So, back to the question: As long as the code is tested in some way that’s good enough, right? Again, yes and no. It’s unrealistic to expect 100% coverage with unit tests, and by definition a unit test doesn’t cover I/O (like accessing a file directory or database). There is also no logical reason to try to set up unit tests on legacy code (older code from previous versions) since in all likelihood it wasn’t written in a way that allows for unit testing in the first place.

So how can unit testing be worth your time? You probably paid good money for your software, and not only you expect it to work “out of the box”, but you also probably expect new features down the road, and even changes to existing features. Luckily, when the developers wrote this new piece of software for you, they wrote unit tests as well. All of your old features’ unit tests are ran every night to guarantee new features don’t break existing features. Any new code written will also have unit tests, so this will continue into the future.

The Catch

Several skeptics to unit testing and Test Driven Development (TDD) claim that unit tests are a waste of time. While I disagree with most of their points, unit testing does require some overhead. Instead of just coding and testing along the way, developers must have an intimate understanding of the feature they are trying to write. The better the understanding, the better the unit test.

This means that a lot more discussion and planning goes into the project creating and any CNAs. It also means that at first, the biggest part of the triangle will be “good”, meaning that for unit tests to be possible, “fast” or “cheap” will have to be eliminated. This will be worth it in the long run though, as the “good” section will get smaller once the unit tests are initially created. Keeping up-to-date unit tests for a codebase will catch most bugs before they become a problem, and will guarantee that new changes will not break existing code. In the long run, unit tests will be worth your time or money.  

 

Author: Jonathan Ferguson