Permalink, Quality Control and Unit Testing, cam, 325 words, 0 comments, Software Engineering, Unit Testing

There is a posting on the perl journal about test driven development and how being dogmatic about a quality approach is never fully fruitful. One of the problems in software is feature volatility and while functional testing offers a mechanism to test features it is also plagued with the same problem.

It has been my experience that unit testing does produce higher quality and more robust code during development. It is more laborious and does take up more time, but the number of times untested code has sucked up two developers for two days each in tracing down difficult and obscure behaviour it is worth it. More so, those that don't cover their code fully with unit tests do have the buggiest code.

There was a time when the bare minimum of quality in a software project was continuous integration and a central source repository. Now, it is unit testing as well. But again, it doesn't require 100% unit testing coverage, or test driven development. One of the things that makes code so durable is that if you get it right once, it tends to work the same forever. So code that has passed QA is normally good for production in most cases, short of gnarly edge cases.

There is also the issue that working code in a crunch environment is valuable, so working code will get pumped out and unit tests skipped. Features are often deemed more important during the development phase and quality only becomes important after feature complete. There is also the issue that quality can be difficult to determine until feature complete anyway as features can be negatively impacted by the different delivery mechanism for data in complex projects when they are incomplete leading to confusing bugs or quality issue reports.

Ultimately however, unit testing has raised the bar on what is the standard for quality in a software project. Codebases without test harnesses of some kind are remiss. (reply)