When I started my career in software development 22 years ago this year, it seemed that unit testing adoption was rather patchy. Whether you wrote unit tests or not, depended upon the environment you worked in. So most developers only used to write unit tests if they worked on a project which mandated unit testing, for example working on a safety critical system or defence project. Or if they worked within a team with people who saw the merits of writing unit tests.

Unit testing seemed to become steadily more popular in the 2000s. I worked on a few projects early on in my career that advocated the use of unit tests. This may have been using a specific tool or creating specific projects to exercise the code that you have written. I remember my team lead at a job that I had in 2005, came in one morning before we started work and demonstrated NUnit to me. I thought this was great and I think it influenced my thinking going forward.

Later with the advent of continuous integration becoming popular in software development, software developers started to use open source unit test frameworks like NUnit. I found that the more places I worked, more people were adopting unit testing as part of their development process. But I still find that software developers don’t write unit tests. So, this article attempts to explore the reasons why developers don’t write unit tests.

You Don’t Know Any Better

You might be a junior developer fresh out of university and may have heard of unit testing at university, but not embraced the benefits of writing unit tests. Never finding the time to be patient with yourself to read up on unit testing and experiment with a framework. You know there must be a better way, but don’t know what it is.

You Are Set In Your Ways

You might have been writing software for years and do your own developer testing and produce robust code. You might then think, what I am doing works for me, why learn another technique?

The Testers Will Find The Bugs

Some developers don’t see it as their responsibility to test the code that they write. They see it as the responsibility of the test team to find the bugs and report the bugs to them to be fixed. The only trouble with this approach is, you will probably end up delivering code which simply does not work. Imagine being the unfortunate testers, picking up the release only to find that it crashes and burns with runs of their test scenarios?

Nobody Sees The Value Of Unit Testing In Your Team

You work in a team that sees writing unit tests as a waste of developers time. There is already a test team in place which runs manual tests against the software release, so why do we need to spend extra effort writing unit tests? There is an attitude of “this is great, but we don’t really have time to do this”. So any efforts to introduce unit testing meet a lot of resistance.

You Inherited A Legacy Code base With No Unit Tests

You are maintaining a legacy application which is still critical for business, but has no unit tests. There is very little in the way of documentation and most of how it is supposed to work is held in a few people’s heads. The software release relies heavily on manual testing which does seem to work, but you still end up with a number of issues after each release. The code base is tightly coupled and doesn’t really lend itself to unit testing. There is no budget left to refactor the code to make it testable, again not seeing the value of investing the time an effort in doing this.

No Incentive To Write Unit Tests

The culture of your development team pays lip service to unit testing. There ends up being a task to write unit tests, but it ends up not being done because of tight delivery timescales. Or if any unit tests are written, they end up being low value tests which instantiate objects and do little more than that. There is a greater emphasis on delivering the code in the time allocated for that piece of work and then moving on to the next piece of work.

The developers seen to be cutting the most code or fixing the most bugs are rewarded. So we end up with a code base which is difficult to change when it goes into production. People have sleepless nights worrying if the change they made may have broken something unintentionally somewhere else. Changing the code ends up like playing a game of Kerplunk.

You Are A Code Firefighter

You have a reputation of solving problems which are of high urgency. There is pressure to get the code fixed and deployed to production as soon as possible. The trouble is, this is often done at the expense of good programming practices. The problem gets fixed or fixed for now, but people feel fearful of changing the code in the future, for fear of re-introducing the problem.

Conclusion

You may identify with some of these reasons for not writing unit tests now or in the past. You may think that these are valid reasons for not writing unit tests. But I think you are missing an opportunity to up-skill as a programmer and make your life as a developer easier and more rewarding by embracing unit testing.

So where do you start your unit testing journey? I have worked with people who did not write unit tests and have embraced writing them. One notable comment from a colleague from my past, which sticks with me is “I can’t imagine writing code without unit tests now”.

• You could start by reading this book or the previous editions: The Art Of Unit Testing
• You could try out the examples on this page: Getting Started With Unit Testing
• Find someone you know who already does unit testing and ask them to help you get started. From my experience people respond well to enthusiasm