Developers often struggle to find and keep track of uncovered lines in their pull requests (PRs). Our latest feature, the Pull Request Coverage Diff View, makes this a problem of the past.
How It Helps You
Hunting down and identifying new lines of code that haven’t been tested is often a tiring manual process that involves a lot of squinting at code and guesswork.
With this new view, you’ll be able to easily identify which new or updated lines of code have been tested and which haven’t.
Imagine reviewing your code coverage changes, just as you would on your Git provider, and seeing every line you either added or updated with embedded coverage data to go along with it.
That’s exactly what you get with this new view—the ability to immediately recognize which new lines have yet to be tested.
How It Works
If you’ve been using Codacy Coverage for some time, you’re probably already familiar with our diff coverage quality gate rule for PRs. This metric enables you to track the number of code changes in PRs that are covered by tests.
You’ve probably even seen the PR coverage diff view if you have Coverage set up for a repository. When opening or updating a pull request in a repository receiving coverage reports, you’ll get your status check results as soon as the reports are processed. If the coverage summary is enabled (which we recommend), you’ll be able to see it right on your pull request.
Here’s an example of what that looks like:
Now let’s take the above example to see how the diff view works. You’ll see that the PR complies with the gates we set up, but there’s still plenty of room for improvement.
We see negative coverage variation and diff coverage that’s barely above the threshold.
To see what improvements can be made, let’s check this PR in Codacy.
We can now see clearly that we’re not testing two changes introduced in the PR: the error path and an added event.
With this new view, you’re seeing not just your code changes but coverage information for each change as well. This enables you to proactively run tests for these code changes and improve your coverage.
We’ve been using this feature ourselves, and it’s been a game-changer for our development team. Our teams have seen coverage levels rise across the board.
Developers are buzzing about how this information has empowered them to take action and boost coverage in their PRs, even when the initial value is already above the desired threshold.
To learn more about this and other features we’ve recently added to the platform, check out our recent Product Showcase video:
If your development team chronically struggles with code coverage, start a free Codacy trial today to see how we can help you fix that!
