News Stay informed about the latest enterprise technology news and product updates.

Is unit testing beneficial?

There is an interesting debate about the pros and cons of unit testing taking place on Despite the fact that test-driven development has increased, unit testing is not a priority, according to a recent poll conducted by Methods & Tools. Poll results show that 17% said unit testing is not performed, and 40% said it was informal. Meanwhile many people say unit testing is critical for improving the quality of software.

Why isn’t unit testing a priority? Developers give the following reasons:

  • 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

What do software testers, QA engineers, project managers, and IT managers think about unit testing? Do you like it when the developers on your team do unit testing — does it improve the quality of the software being created? Should they do it only if they’re going to do it well — not to simply say they did it?

I’d like to know what you think.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

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. Worse, without process in place to unit test the required fixes, the environment destabilizes such that you can't see the if the system test case passes because of other problems.
A fable: A couple had a house built. The carpenters erecting the timber framing did their best to get the lengths correct, the uprights upright, the levels level, and the squares square, but did it all by eye without bothering to [I]measure[/I] the quality of their work. As work progressed, the doors wouldn't fit the door frames, the windows wouldn't fit the window frames, one wall leaned inwards, another leaned outwards, and all four walls were of slightly different heights. When the architect and building inspector came round to view progress, they were rather cross. "Didn't any of you think to use rulers, plumb bobs, squares, or levels, to check the quality of your work before moving on to the next thing?" they asked. "Oh no," said the carpenters, "We only build the house, Testing its quality is your job, not ours." Software development is often considered a craft rather than a branch of engineering. There are good reasons for this, one of them being that software development is generally driven more by fashion than by what has been scientifically proved to work, whereas true engineering disciplines work the opposite way round. But true crafts-persons have a remarkable ability to take pride in the quality of their work, and while software developers can often take just pride in [I]their[/I] handicraft, it's also true that they often make little effort to [I]control [/I] its quality. "No-one is better placed to control the quality of work done, than the person doing it" (W. Edwards Deming)--as [I]normal[/I] carpenters would when putting up timber framing. But it's also true that effective quality control requires the appropriate personal [B]E[/B]quipment: [B]E[/B]nthusiasm for quality (the desire to do the best possible job); [B]E[/B]nablement for quality (provision of appropriate knowledge, understanding, tools, and skills); and [B]E[/B]mpowerment for quality (the opportunity to address the root causes of quality failures). Software developers, like most people, generally want to "do a good job", but often lack a detailed understanding of what that means. This is largely because they generally receive little or no training in [I]how[/I] to measure the quality of their own work. In a three- or four-year degree course in so-called software engineering, computer science, or similar, software developers typically learn only enough about testing to be able to complete practical assignments: perhaps a half-day tutorial, which makes no attempt to instill them with [I]enthusiasm[/I] for the subject, or teach its value or importance, or provide practical help in how to do it on a day-by-day basis. This appears to be a world-wide phenomenon. Absolutely, developers should have the [I]pride[/I] to test their own code thoroughly. This includes the realisation that every line of code has been individually hand-crafted and therefore is individually likely to be buggy until proven otherwise--in other words, 100% code coverage should be an absolute minimum standard, despite its current unfashionability in some quarters of the testing world. But where studies have been done, they have shown that Unit Testing typically achieves no better than 30% code coverage; when their software falls into the hands of "the Test Team", the developers actually know less than a third of what the software really does. This accounts for much of the hard time that Ralph Perry and other System Testers commonly experience. They're in the position (to change the metaphor) of test drivers for a new car which was designed and assembled with very little testing along the way. Will it even start? Will they be able to stop it? What'll happen in between? No-one can make a reliable prediction ... On the face of it, then, unit and component testing (the developers' responsibility) are vitally important. But before finishing, I'll make a final observation about Empowerment: the opportunity to address the root causes of quality problems. In many software development environments (certainly not all), writing formal specifications is not only possible but wise, except that it's often entrusted to people with the same problem as the developers: they receive little or no training in how to measure and control the quality of their own work. The result is specifications that, to put it bluntly, tell vague lies about the software, instead of detailed truths. Poor specifications may be the source of 40% to 75% of the defects that hit System Testing. Inspections provide an extremely cheap (when properly understood and used) and cost-effective way of providing quality control of specifications, designs, code, and documents generally. And what's been found when they've been used is that software design and coding may proceed almost three times faster than usual; that total test execution time may be reduced by 80% or more; and that even [I]thorough[/I] unit testing may find so few defects that it ceases to be worth doing. Meanwhile, developers keep building their timber houses without benefit of rulers, squares, levels, or plumb-bobs, and having to tear them down and start again, sometimes from the beginning. And then eventually the family moves into the house ...
Unit testing is a very crucial and important part of STLC and I don’t agree with people neglecting it. People who say it is an unimportant or not do-able activity, in a way, are skipping serious testing of the product. [B]A lot of flaws or shortcomings of the product can only be tracked only through unit testing.[/B] In our scenario, UT is an integral part of the testing and is a must-do for all products that we test.