Why Do We Unit Test? And What’s the Purpose of Code Coverage?
Use code coverage as a tool to help you find untested code, not as an ultimate goal.
Join the DZone community and get the full member experience.Join For Free
There are many unit testing frameworks that help us with our unit tests. In Java, we have JUnit and TestNG, both have been around for a long time. The key part they help us with is making assertions about the results of our code under test, checking the results, and confirming that when we call our code, it returns the expected results.
So, why do we unit test? As developers, we want to know how our code works and that it does what it is supposed to do. We use unit tests to give us confidence about our code so that we know it works.
We can use unit tests to help with code changes or refactoring efforts to improve existing code. If existing tests are available, you can use them to check that they are showing you where the issue is that you need to fix (assuming there’s a test for that part of the code) or check that the existing code is working before your refactoring changes.
A typical flow for using unit tests to help with a defect fix looks like:
Run test, confirm test fails. Make code fix, confirm test passes. If the unit test for the related code doesn’t have an existing test for the code where the issue is, add a new test. Write a test for the expected result which should initially fail, rerun after the code fix, and now the test should pass to confirm your fix is working.
Run other related tests in the same area to check that there are no unexpected impacts to other existing code.
We can also use unit tests as part of a CI/CD pipeline – when our tests pass, the code is ready to include in a new build, and depending on your development process, ready for additional tests, integration testing, UAT testing, and promotion into production.
Many industry studies have shown that it’s always cheaper to find and fix defects in our code earlier than later. The time invested to develop unit tests saves us in the long run if we can find issues earlier and avoid finding issues later, e.g. in production.
Any number of unit tests does not prove that our code is 100 percent correct; however, neither does it prove the absence of bugs. If our unit tests are effective though, they can give us confidence that our code is working as expected for a range of tested inputs.
What Is an Effective Test?
An effective unit test must have assertions to check and confirm the code when executed with given parameters returns the expected results. In JUnit, the framework provides a number of assert statements, like
assertEquals() that you use to confirm the expected results.
A unit test without assertions that only calls the code under test is not an effective test. Without assertions, the test is useless if you’re not checking the expected results.
The same is similar for
assertNotNull(). If the only thing your test does is check that there’s a non-null result, this doesn’t confirm that the code is returning the expected result; it only confirms a value is returned. This is not particularly useful when we expect a unit test to confirm that the code is returning the expected results (i.e. it is working).
For any given method that takes parameters, you should have a range of test methods to confirm the expected results for that range of input values. You should obviously test with expected/valid input values, but you should also test with a few unexpected/invalid values: high values, low values, empty, and short and long strings. In all cases, you should assert and confirm that the method returns the expected results.
How Does Code Coverage Relate to Unit Testing?
Code coverage tells you how much of your code was execute by your tests. As a tool, it is useful during the development of your unit tests because it helps highlight where your tests may have missed paths through the code. For example, if the code you are testing has an if..then..else condition and your test calls the code with parameters that cause the if condition block to be tested but not the else block, code coverage helps highlight untested code.
The problem with code coverage, though, is that, by itself, code coverage is not an indication of effective tests or even working tests. If you have a test without an assertion that calls a method with a single block of lines of code and each of those lines executes, code coverage will report 100 percent coverage on this block. Without an assertion, this test doesn’t test that the code works and, therefore, is worthless. It does have 100 percent code coverage. This is why relying on code coverage alone is not useful, or sensible, because it doesn’t tell you how effective your tests are. It only tells you how much of the code was executed. Code that is executed by a test but is not confirmed if it is returning expected results or not with assertions is just executed code, not working code.
Remember your assertions.
Use code coverage as a tool to help you find untested code, not as an ultimate goal: writing tests to achieve code coverage is not useful. Instead, developing effective tests is your goal.
Published at DZone with permission of Kevin Hooke, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.