Mocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Explore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely — and automatically — with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
Regression testing is an important step in the release process, to ensure that new code doesn't break the existing functionality. As the codebase evolves, we want to run these tests frequently to help catch any issues early on.
The best way to ensure these tests run frequently on an automated basis is, of course, to include them in the CI/CD pipeline. This way, the regression tests will execute automatically whenever we commit code to the repository.
In this tutorial, we'll see how to create regression tests using Selenium, and then include them in our pipeline using GitHub Actions:, to be run on the LambdaTest cloud grid:
Regression testing is an important step in the release process, to ensure that new code doesn't break the existing functionality. As the codebase evolves, we want to run these tests frequently to help catch any issues early on.
The best way to ensure these tests run frequently on an automated basis is, of course, to include them in the CI/CD pipeline. This way, the regression tests will execute automatically whenever we commit code to the repository.
In this tutorial, we'll see how to create regression tests using Selenium, and then include them in our pipeline using GitHub Actions:, to be run on the LambdaTest cloud grid:
1. Overview
Software testing helps us ensure our code works correctly, which makes it an important part of the development process. When discussing testing, terms such as code coverage and test coverage may arise. Although they both represent a way to measure the effectiveness of our codebase, they refer to different concepts. Thus, we shouldn’t use them interchangeably.
In this tutorial, we’ll learn the differences between code and test coverage and discuss what each means.
2. Code Coverage
Code coverage is a mechanism that measures the portion of the source code covered in tests. It represents one of the forms of white-box testing, which requires access to source code and takes implementation details and the internal structure of the code into account. Code coverage is primarily done by developers in unit tests.
There are several ways to measure code coverage:
- Statement/Line coverage checks the number of statements executed at least once during testing.
- Branch coverage calculates the percentage of covered branches in a decision-making process.
- Condition/Expression coverage ensures that each condition is evaluated as true or false at least once.
- Function coverage computes how many methods were called at least once.
Code coverage results are often shown as a percentage, measuring the ratio of the source code covered by tests.
Furthermore, we usually need an external tool to measure code coverage. For Java-based applications, we can utilize tools such as JaCoCo or Cobertura. These can help us generate a detailed report showing which parts of the source code are covered and which aren’t.
The most common code coverage type is statement coverage, which we can calculate using the general formula:
Statement coverage = (Number of executed statements / Total number of statements) * 100Similarly, we can calculate other code coverage types.
2.1. Code Coverage Advantages
Next, let’s examine the advantages when it comes to code coverage. First, it offers results in quantitative metrics.
With code coverage tools, we can recognize parts of the source code we didn’t cover by tests.
In addition, we can detect unused source code more easily, which allows us to remove unnecessary code.
2.2. Code Coverage Disadvantages
Finally, let’s discuss some of the code coverage disadvantages.
As mentioned, code coverage only calculates the amount of source code executed throughout automated testing. It doesn’t guarantee that our tests are valid and correct.
We can have poorly written tests while achieving high code coverage. Considering this, 100% code coverage doesn’t necessarily mean our code is free from bugs and issues. Moreover, forcing 100% coverage may lead to useless tests written just to increase code coverage.
3. Test Coverage
On the other hand, test coverage is a metric we use to describe how much our testing covers the application’s functionality.
The main goal of test coverage is to determine how well the application is tested, taking use cases, requirements, functionalities, risks, different environments, and other factors into consideration. With such coverage, we can cover all necessary features, business requirements, and edge cases.
Test coverage is calculated by the QA team from the end user’s point of view. It helps identify which parts of the application have been tested and which parts might still need our attention. Although it may take unit tests into account, it also encompasses additional aspects, including functional testing, integration testing, and acceptance testing.
Additionally, test coverage can be related to both automated and manual testing. We can use tools such as Selenium, Playwright, or Cypress for automated testing. These tools can help us calculate test coverage more easily than manual testing.
Unlike code coverage, the focus of test coverage is ensuring we’ve covered the features of our application.
There are several ways to define test coverage:
- Product coverage checks whether tests cover overall product functionality.
- Risk coverage examines how well tests cover vulnerable parts of applications, such as security.
- Requirements coverage ensures that the tests cover all requirements and use cases.
- Compatibility coverage measures how well the application works on different platforms, browsers, and operating systems.
- Boundary value coverage examines how efficiently tests cover edge cases.
Test coverage, unlike code coverage, is more qualitative than quantitative, which makes it more challenging to quantify. However, if we want to calculate requirements coverage as an example, we could use the formula:
Requirements coverage = (Number of covered requirements / Total number of requirements) * 100Notice the expression is similar to code coverage measurements, but the inputs to test coverage calculations can be harder to quantify.
3.1. Test Coverage Advantages
Let’s look at some of the positive aspects of test coverage.
First, it ensures that every aspect of the application has been examined and identifies functionalities that still need to be tested.
Unlike code coverage, it doesn’t necessarily require technical knowledge, especially if we’re talking about manual testing. Consequently, it’s easier to implement.
It represents a black-box testing method where the tester doesn’t have access to the source code. It merely focuses on the outputs retrieved from the given inputs.
In addition, this type of testing focuses on the overall user experience.
3.2. Test Coverage Disadvantages
Just like code coverage, test coverage doesn’t guarantee the application will run without issues.
Since we don’t have insight into the source code, we can’t measure some aspects, such as codebase quality.
Additionally, we can’t detect unused parts of the source code with test coverage.
4. Comparison Between Code Coverage and Test Coverage
To sum up, let’s show the differences between code and test coverage with a comparison table:
| Code Coverage | Test Coverage |
|---|---|
| Measures the percentage of the source code covered with tests. | Measures the number of covered requirements with tests. |
| Quantitative measurement. | Quantitative or qualitative measurement. |
| Ensures tests cover all source code. | Ensures tests cover all application’s functionalities. |
| Done by developers. | Done by QA. |
| White-box testing approach. | Black-box testing approach. |
| Usually done within unit tests. | Usually done in acceptance tests. |
5. Conclusion
In this article, we learned the difference between code coverage and test coverage in software development.
To sum up, the confusion between code and test coverage appears because they overlap on some level. However, they aren’t exactly the same. Code coverage focuses on the amount of code executed through automated tests. We usually compute it using tools that analyze the codebase directly during the test execution. On the other hand, test coverage measures how well the tests cover the application’s functionality, user requirements, and potential risks.
