Unit testing is an Integral part of extreme programming
Unit tests are a prerequisite for the Extreme Programming methodology. Extreme programming is essentially a “test-everything-that-can-possibly-break” strategy. Writing unit tests with this methodology makes development and code refactoring simpler, integration easier, and creates living documentation. Which brings us to our next point…
Unit testing provides documentation
Unit tests are a kind of living documentation of the product. To learn what functionality is provided by one module or another, developers can refer to unit tests to get a basic picture of the logic of the module and the system as a whole. Unit test cases represent indicators that carry information about appropriate or inappropriate use of a software component. Thus, these cases provide the perfect documentation for these indicators.
R2: Reusable and Reliable
Within unit tests environments, the individual modules of a product become isolated from one another and have their own area of responsibility. That means that the code is more reliable—it’s been tested in a contained environment—and therefore, reusable. Reusable code is a win-win for all: It’s clean, efficient, and consistent. All of this is accelerated with unit testing.
Unit testing helps gauge performance
Wouldn’t it be amazing if you could find out the possible breaking points of your software before it goes into production and users spot them on their own? Unit tests can provide such an opportunity, and can prevent the unnecessary effort of searching for solutions to non-existent issues. For instance, if you work on a hashed list, you may face a need to check how it will perform if the list grows. The rate of growth is unknown. What you will likely do from here is apply unit tests to try out scenarios of varying levels of probability — from highly probable to absurd. If you are already sure that the number of items in the hashed list won’t surpass 10,000 under any circumstances, at 100,000 you are all set and can stop at this point. You have proven your software capacity is good enough, and there’s no need to spend more time testing.
Unit testing improves code coverage
Okay, so software unit testing is great, but how much test coverage is necessary? American software engineer Robert C. Martin, also known as Uncle Bob, argues that the goal of test coverage should be that 100 percent of the code is covered. Opinions among developers on this issue differ: some support a complete code coverage policy, while others consider this practice redundant — a topic too lengthily for the purposes of this article. In any case, when writing unit tests, you can use many tools that determine the total percentage of the coverage of a project, separate module, or function. These tools are also able to graphically display the code sections covered by tests and indicate the sections in the code for which it makes most sense to write unit tests.
It’s very useful to know at the active code writing stage if a particular line will ever be executed or you if can painlessly remove it. If you have valid unit tests, you can have coverage metrics on hand right away, and decide whether a code line is ever relevant. If it’s not, consider expanding your code coverage with one more test. If your test suite already accounts for all possible scenarios, eliminate the unnecessary code. However, the need for more tests is a sign of increasing cyclomatic complexity.
Unit testing reduces code complexity
Cyclomatic complexity is a quantitative measure you can use to understand exactly how complex the program and its code are. The more paths are implied in a single code block, the higher the complexity. Namely, when there’s no control flow statement in the source code, the complexity rate stands at one, and with “if” statements it gradually rises to two or higher. As you can imagine, this is where achieving perfect unit-test coverage becomes a difficult task. The more conditional statements the code has, the more complex the code block is.
Once the creation of unit tests becomes cumbersome, it signals that the code might be overcomplicated too. But without unit tests objectively answering the question of whether your code works or not, all you have is your own assumption. With unit tests, you have concrete proof.