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.
Latest posts by Andrew (see all)
- On Developers and Von Moltke’s Leadership Matrix - November 9, 2015
- Andrew’s Coding Corner- Beware the Sunk Cost Fallacy - November 3, 2015
- Andrew’s Coding Corner – Unit Test, Young Man, and Grow Up With the Code - October 27, 2015