Andrew’s Coding Corner – Unit Test, Young Man, and Grow Up With the Code

At most of places I’ve worked Unit Testing is a “nice-to-have”. By that, I mean it would be great to implement, but isn’t considered essential to the operation of the team, or the success of the project. This opinion isn’t unique to the places I’ve worked, as I also see it as an “optional” skill on many job listings. Heck, for a long time I bought into that opinion.

However, some experience working with TDD (Test Driven Development) and Unit Testing has shown me the error of my ways. With TDD, it’s amazing how much cleaner code can be and how few regression issues occur. It’s helped me iron out problems with my code and forced me to think about code design. So instead of a giant gloppy mess of spaghetti code, I end up with a clean, sensible code that does the minimum required to achieve its purposes.

I understand why managers and teams are hesitant to introduce TDD into their coding process. Many existing employees and new hires don’t have experience with TDD/Unit Testing. Thus, a learning curve is required. In addition, writing the tests (and more importantly, internalizing the Test Development Test Refactor mindset) takes time, which means there will be overhead that will affect capacity in your iterations. Most frequently, the biggest obstacle to implementing TDD is the code base is just not built in a way conducive to introducing unit testing. The benefits of unit testing can be hard to explain to product managers and the “higher ups”. After all, they are already running around yelling “EMERGENCY” at every story, task, or bug that’s out there. It can be hard to say that you need to bump a couple stories out of the iteration so the developers can implement testing that only they will use.

The best counter to those concerns is a little investment up front in Unit Testing will pay big dividends in the iterations (and years) to come. With a suite of automated tests in place, the dreaded problem of “fixing in one place breaks your code in another” can be caught before it goes to QA, let alone before it gets released. Cleaner code means faster turnaround through QA, and fewer hot fixes, which will not only please management but also the DevOps folks. It also encourages your development team to “own the code”. They’ll have a better idea that the code isn’t just what they work on, but the code as a whole.

So how do you do it? Don’t try to pull a 180, gradually change things over. For a completely new project, make sure you start using it from the beginning. The same thing goes for completely new classes, or for classes that can be easily refactored. For the rest, make sure you take time each iteration to refactor code until you can bring it into the testing fold. Eventually, you’ll have as much coverage as you need. You’ll also have a happier development team, cheerier customer service reps, and more satisfied customers.



I've been a programmer for almost 15 years, back in the rough early days of PHP 3. Am well versed in the world of PHP and MySQL. I have a deep appreciation of ZF2 and Doctrine. The thought of all the spaghetti code I've dug through (and written) keeps me up at night sometimes. My profile picture is not of me.

Leave a Comment

Your email address will not be published.