Click here to Skip to main content
Click here to Skip to main content
Technical Blog

Tagged as

Unit Testing: Good Idea/Bad Idea?

, 27 Mar 2013 CPOL
Rate this:
Please Sign up or sign in to vote.
Unit testing is not a "one size fits all" solution. It's important to have the necessary conversations to find a happy medium.
The phrase "unit testing" evokes a wide variety of opinions within the developer community. At this point, most individuals understand the concept through direct experience or community osmosis. In fact, the TDD (test-driven development) model is initiated through the development of a failed test that satisfies a new feature. Once completed, a developer performs the minimum amount of coding required to pass the test. This continues through an iterative cycle until the code meets an acceptable standard. Over the past 10 years, dozens of unit testing frameworks have been built by the developer community to satisfy the need for unit testing. Frameworks exist for compiled languages (e.g., Java, C++, .NET), interpreted languages (e.g., JavaScript, PHP, ASP), and even databases (e.g., SQL, PL/SQL, MySQL).

Unit testing has a variety of well documented benefits. Unit tests find problems earlier in the process, which saves QA testing efforts. Unit tests allow programmers to have a high level of confidence when refactoring code because broken tests identify missing logic. Unit tests simplify the integration process of multiple components. If each component was built and verified by unit tests, validating the integration of those pieces consumes less time. Unit tests provide a quasi living document of functionality. This is invaluable when there is a lack of documentation. Unit testing can also replace a formal design document because the unit test specifies the form, function, and desired result.

The previous statements paint a positive, albeit wide, picture of unit testing; unfortunately, every concept has its limitations and concerns. There are a few difficult questions with unclear answers. Below are a series of observations:
  • As with the original code, building a unit test relies upon a developer's coding ability.
  • Unit testing does not eliminate other testing requirements; it complements them. This extends the amount of time to complete a feature.
  • Unit tests can only "show the presence or absence of particular errors; they cannot prove a complete absence of errors."
  • The initial addition of unit tests to a per-existing project or code base is time consuming.
  • Where does unit testing start and stop? Does a website require JavaScript, server-side code, and database unit testing?
  • Where is the point of diminishing returns? In a non-TDD world, when does a developer stop building tests for a feature? More tests do not equal less bugs.
Although these observations might provide a gloomy outlook, they should not deter anyone from implementing unit tests. The benefits are still real. They simply highlight the hyper-vigilance required to implement. Unit testing is not a "one size fits all" solution. It's important to have the necessary conversations to find a happy medium. As with any new process, buy-in is essential. When implementing a unit testing framework be sure to educate/train all those involved. Integrating unit testing into the design and defect processes further ensures its successful assimilation.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Zac Gery

United States United States
Software Developer, Mentor, Architect and UX/UI craftsman. Also, a psychology nut that loves curling.
Follow on   Twitter   Google+

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.1411023.1 | Last Updated 27 Mar 2013
Article Copyright 2013 by Zac Gery
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid