Why Don't We Unit Test?

One of the hallmarks of a professional software developer (as opposed to someone who just gets paid to write code) is that the professional developer puts time and effort into making sure that the software they are building works as expected and is without undesirable side effects.? Over the years this has been done many ways ranging from manually exercising the software as an end user would to writing a “harness” to run through specific scenarios with minimal direct interaction.? In the early 2000s, I watched and participated as developers in both the .NET and Java world reached the collective conclusion that automated unit testing using standard frameworks were the way to go.? Having executable unit tests that live with the application code itself provides a level of assurance that new changes work as expected, but that all pre-existing functionality that was covered with unit tests continues to work as it did before the current changes.

If the developer community as a whole agreed two decades ago that automated unit tests were a critical part of plying our trade in a professional manner, why then is it still considered “normal” to find development organizations where “we know we should be unit testing, but they won’t let us” (where “they” is alternately different roles ranging from IT management to business stakeholders to the magic eight ball that is consulted for major design decisions)?? I contend that a large part of the reason behind this is that we as developers go out of our way to create a scenario where we will be directed not to do what we know we’re supposed to know is right.

The first way that we encourage those with authority over a project to proscribe automated unit testing impacts mainly business stakeholders and is accomplished by making a truthful statement that only includes half the story – “even if he hit 100% code coverage in our automated tests, there is still no guarantee that we are testing the right things and there could easily still be bugs”.? Business stakeholders hear this statement and often come to the conclusion that if IT is telling them that unit testing still will not provide assurance of a working system, there is no reason to expend the time and effort.? This is easily combated by providing the “but” that is the rest of the story.? Unit testing at 100% coverage indeed may still miss some critical piece of how the software is going to work, but unit test coverage of 10% is much less likely to provide assurance that a correct test can give and also much less likely when a bug is discovered to have a mitigation workflow of fix the test, fix the bug, make sure all the tests still work. It's also important when having this discussion to acknowledge that the more complete test coverage of code is, the less likely it is for unanticipated change to sneak in while delivering subsequent releases - which ultimately means the business stakeholders can have higher confidence in allowing developers to deliver change as quickly as it's needed.

The second way that we encourage decision makers to direct us to skip unit testing impacts mostly managers and PMs.? In this scenario, the developer communicates testing as something that is separable from the development effort and with its own “line item” from a cost perspective.? We do this by giving a status report that sounds something like “I got the development work for feature XYZ done and just need to right some unit tests.? I should be done by the end of the day or tomorrow at lunch at the latest”.? This suggests that the “real work” is done and you’re going to spend an entire day on extra stuff when you could be moving on to the next feature.? In this instance, developers are much better off to establish a working agreement that states “done means the code is written, tested, and functions as expected”.? That way, your status report becomes “I’m making good progress on feature XYZ and expect to wrap it up today or early tomorrow”.

Part of being a professional developer is making sure that we do everything in our power to ensure that we have an environment that allows us to do the job right.? By thinking about the way we present unit testing concepts to members of the team that are not professional developer, we can often protect our mandate to adhere to industry accepted practices.? Why not give it a try on your next or current project?