A few weeks ago I wrote about how many programmers don’t consider unit testing a priority. Reasons given:
- They don’t know about it
- Good unit tests are hard to write
- It’s a waste of time and productivity
- Writing the tests would take too long (especially if they’re doing frequent iterations)
- Regression testing is more effective
Since writing that editorial, a few people have spoken up in favor of unit testing, saying it must be a priority.
Ralph Perry wrote, “Without an effective unit and integration test process, my experience is QA/system test becomes a dumping ground, code/build/dump with frequent loads just to get to a stable testable product.”
While Jaideep Khanduja wrote, “A lot of flaws or shortcomings of the product can only be tracked only through unit testing.”
This past week Kevlin Henney, an independent consultant and trainer based in the UK and a frequent contributor to SearchSoftwareQuality.com, added to the discussion with his article, “Making unit testing a priority.” Henney says there is an expectation that programmers do some sort of testing of their own code. The key is that they must write good unit tests, and doing so takes practice and skill. Bad unit tests “can be worse for a project than no unit tests at all,” he said.
But saying you won’t run unit tests because it’s hard to do well is “a curious and somewhat dubious justification,” he said. Instead, make an effort to improve your skills. Your projects will be better off for it.