A Guide to Code Coverage Tools for C# in 2026

In this post, we’ll walk through 8 different .NET code coverage tools and list their features to help you make a decision. The tools covered are Visual Studio Code Coverage, JetBrains dotCover, NCrunch, AltCover, Coverlet, Fine Code Coverage, NCover and NDepend.

If you just want the short answer: for free coverage in your CI pipeline, reach for Coverlet; for coverage painted right in the editor, use Fine Code Coverage or Visual Studio (now free for everyone in 2026); and if you live in ReSharper or Rider, you already have dotCover. The rest of this guide explains the trade-offs so you can pick with confidence.

Introduction

What Is Code Coverage and Why Do It?

Code coverage tells you which lines of code your test suite executes and which it doesn’t. Here’s the simplest example — a dubious implementation of division:

Say that’s the only method we have, and we wrote a single unit test that calls Divide(2, 1) and asserts it returns 2.

We would then have 67% code coverage. Why?

The test runs the conditional and the return x/y statement — two-thirds of the method — but no test ever executes that last line.

That’s the “what.” The “why” is just as practical: coverage analysis exposes the holes in your testing. Here, it tells us to go test the case where y is 0.

What Are Code Coverage Tools?

Computing coverage by hand like that gets old fast, so developers automated it. Just about every language and stack now has tools that measure how thoroughly your tests cover your code.

Don’t confuse that with test quality, though. Coverage measures how much code runs — not how much of the output you actually assert. That still leaves a confusing array of options in the .NET ecosystem, so let’s walk through them.

How to Measure Code Coverage in C# with dotnet test

Before we tour the tools, here’s the fastest way to get a coverage number on any modern .NET project. First, the cross-platform Coverlet collector ships with the standard test templates, so most of the time you just run:

Next, that drops a coverage.cobertura.xml file into the TestResults folder. To turn that XML into a readable HTML report, install ReportGenerator and point it at the file:

Prefer Microsoft’s built-in collector? Then swap in the "Code Coverage" friendly name instead, and convert the binary result with the dotnet-coverage tool. In short, either way you now have line and branch numbers. The rest of this post is about the tools that make that data pleasant to live with.

Coverlet (the de facto default)

We just used it above, so let’s start here. Coverlet is the de facto default for .NET coverage today. It’s the collector wired into the dotnet test --collect:"XPlat Code Coverage" command, it’s free and open-source, and it’s part of the .NET Foundation. It measures line, branch, and method coverage, on .NET Framework under Windows and on .NET Core everywhere. Its strengths:

• Lightweight: it plugs into your test projects without weighing them down.
• Free and open-source: no license cost, and an active community keeps it moving.
• Flexible: you control exactly what gets instrumented or excluded.
• Robust: it reliably pinpoints the code that needs more testing.

It also emits Cobertura, OpenCover, lcov, JSON and TeamCity formats, so it slots into pretty much any CI dashboard. And if you work in Visual Studio Code, Coverlet pairs nicely with it as explained here.

Visual Studio Code Coverage

For years Visual Studio code coverage was an Enterprise-only perk. However, that changed in 2026: built-in code coverage now ships in the Community and Professional editions too. As a result, a lot more developers get it out of the box, for free.

And it’s as simple as this screenshot.

From the Test menu, pick Analyze Code Coverage for All Tests, or run it on a selection from Test Explorer. You can read about this in more detail at the Microsoft documentation site. Overall, it’s a comprehensive option that requires very little additional work. And it has cool features:

• It reports coverage percentages at various granularities (e.g., assembly, class, etc.).
• You can select all of your tests or subsets of them.
• You can have it paint your IDE, meaning it lets you actually visualize the coverage as you look at your code.
• It comes from Microsoft, so you can expect plenty of maintenance and support if you invest in its usage.

Rider’s and ReSharper’s dotCover

If you have a Visual Studio Enterprise license, your life is good in a lot of ways. But if you don’t, shelling out $3,000 per year is probably going to be a bit of a deal-breaker just to see code coverage.

And it should be a deal breaker. Of course, Visual Studio Enterprise is an AWESOME tool, but if the only reason you’re buying it is to see code coverage, you have significantly cheaper options.

Take JetBrains dotCover, for instance. It comes bundled with JetBrains’ commercial offers, which cost only $349 to $779 per year. So you get coverage analysis, and you also get Rider and ReSharper, which are really cool tools in their own right.

With dotCover, you get plenty of features as well. Some highlights include:

• Detailed reporting.
• Test runners. You can also run tests through the JetBrains dotTrace profiler to measure performance.
• Both Visual Studio and CI integration of coverage measurements.
• Navigate to covering tests.
• A cool “hotspots” view that calls out risky methods.
• IDE green/red statement painting.

NCrunch

I’m going to switch gears a little now, having given treatment to some major players in the .NET code coverage tools space. So far, I’ve listed what I think of as “traditional” code coverage tools.

NCrunch is different.

Indeed, it is a code coverage tool, and it will give you code coverage data. It will also give you the IDE painting that some of the other tools give you. (If you look at the screenshot of my environment below, you’ll see red and green dots — those are NCrunch telling me that tests are failing and passing, respectively).

But it gives you a killer feature as well.

Meanwhile, NCrunch constantly runs your tests, in real-time, as you type. This is Live Unit Testing.

With NCrunch, you don’t need to run your tests, or even compile, to get feedback on whether your code changes are breaking anything. The dots will change as you type. Below, the green passing-test indicators along the left side of the IDE show the results of live unit testing:

Also, note that the NCrunch pricing is very reasonable, starting at $159 to $289 per seat for an individual developer. Of course, NCrunch has other features besides that killer one, as well:

• Small and customizable memory footprint.
• Inline exception details and easy VS-integrated debugging.
• Mature product that has been in development for over 15 years.
• Safe multi-process parallel execution of tests, able to scale out over a grid of remote machines for more capacity.
• Passive collection of both inline code coverage and performance metrics.
• Intelligent execution able to target only the tests impacted by a given change.
• Very fast wall times on test execution and able to work with very large test suites.

AltCover (formerly OpenCover)

For a few years now, the free and OSS tool AltCover has stepped in as the go-to replacement for the well-known OpenCover, which is now in maintenance mode (its GitHub repository was archived back in November 2021).

AltCover is a .NET code coverage tool that distinguishes itself through its open-source nature and a focus on simplicity. Developed in F# by Steve Gilham, it aims to be a lightweight, easy-to-use option for a straightforward coverage workflow. Notably, it features:

1. A command-line tool designed to capture .NET code coverage. It supports the .NET Core, .NET Framework and Mono runtimes.
2. Seamless integration with MSBuild tasks, with solid support for driving the tool, including dotnet test functionality.
3. A versatile API that exposes its core functionality. This API is extendable and plugs into popular build automation tools like Fake and Cake.
4. Extended PowerShell compatibility through a dedicated module compatible with both PowerShell 5.1 and PowerShell Core 6+. This module includes a cmdlet for running AltCover plus extra cmdlets for manipulating coverage reports.
5. A specialized coverage visualizer tool, built on the cross-platform AvaloniaUI toolkit.

Fine Code Coverage

Fine Code Coverage is the new kid on the block. It is a free Visual Studio extension designed to surface coverage data directly inside the IDE. Moreover, it works with all Visual Studio editions, including the Community one, and wraps tools like Coverlet, OpenCover and Microsoft’s collector behind a friendly UI.

As a result, you’ll see which lines are covered and which aren’t right in the Visual Studio editor.

Fine Code Coverage also adds a dedicated tool window. This window features tabs that surface useful insights into the extent of code coverage, with detailed information on the covered lines of code.

(Fine Code Coverage screenshots taken from Matthew Regis’ blog post.)

NCover (now in maintenance mode)

So far, we’ve looked at a couple of code coverage tools that come bundled with other products. So while they integrate nicely into your development environment, they aren’t exclusively focused on the subject of code coverage.

NCover, on the other hand, is solely focused on that. By specializing, NCover provides extremely detailed information, not only supporting measurements of coverage but also integrating it for the whole team. Moreover, it tracks trends in coverage and provides detailed reporting.

In short, NCover is a comprehensive tool for this purpose. Some features include:

• Detailed and centralized data about coverage.
• Extensive documentation and user support.
• 32- and 64-bit support, plus memory consumption optimization.
• IDE painting.

Unfortunately, as of 2026 NCover is in maintenance mode, so don’t expect new features.

Beyond Raw Coverage Data with NDepend

Finally, I’ll close out (not surprisingly, on the NDepend blog) by mentioning NDepend.

While NDepend doesn’t directly measure code coverage, it happily imports the data from other coverage tools and lets you do some really powerful things with it.

For example, NDepend gives you tons of metrics out of the box, and when you combine those with the imported coverage data, you can do important assessments of your codebase, such as assessing method risk. You can also make use of NDepend’s heat map capabilities to get powerful visuals of where you have good coverage and where you don’t.

Ruling Code Coverage

But my favorite part, personally, is how you can combine this data with CQLinq to create your own rules and measurements around coverage. Many rules are provided by default, like:

• Code should be tested: this rule pinpoints untested code. It also offers a smart estimation of the effort required to write tests to cover untested code.
• New Types and Methods should be tested: this rule spots new but untested code added since the baseline. Clearly, new classes deserve special testing focus. A similar rule exists for untested refactored code.
• Methods should have a low C.R.A.P score: this rule computes a Change Risk Analyzer and Predictor (CRAP) index. This metric helps spot code that is both complex and untested.

A Lightweight Report with All Coverage Data

The NDepend report also comes with a comprehensive overview of the coverage of your application. You can easily browse code coverage by source files.

Then, for each source file, you can drill down into which statements are covered and which aren’t:

The sky is the limit when it comes to combining test coverage data with other metrics about your code. NDepend can also generate a heat map for you:

And that brings us back around to my initial warning at the beginning.

Code coverage isn’t something management should use to take developers to task. Rather, it’s something developers should use to make sure they’re satisfied with their codebases. So use one or more of these tools to measure your coverage, and then use NDepend to turn that data into seriously actionable information.

Then you’ll have the sort of clean, reliable codebase that management doesn’t ever worry about.

Which .NET Code Coverage Tool Should You Choose?

Ultimately, there’s no single “best” pick — it comes down to your budget, your editor, and your CI setup. Here’s a side-by-side recap to compare at a glance.

A quick way to decide:

• Want it free and running in CI? Then start with Coverlet, plus ReportGenerator for the HTML report.
• Want coverage painted in the editor for free? Try Fine Code Coverage, or Visual Studio 2026 itself.
• Want instant feedback as you type? NCrunch’s live unit testing is hard to beat.
• Already on ReSharper or Rider? dotCover is right there.
• Want to turn coverage into rules and risk metrics? Feed any of the above into NDepend.

Bonus: Our approach to Coverage at NDepend

Edit: 11th of January 2024: Patrick Smacchia, CTO at NDepend, added this section.

Which tool do we use to obtain coverage data?

We have been using dotCover for many years. Here are the reasons why:

• The dotCover test runner and test profiler are great tools. They are fast enough, which is essential given the size of our code base (roughly 5,000 classes).
• It is easy to integrate into our CI/CD (although a bit slow).
• It is easy to gather the coverage files that NDepend then uses to generate reports. We dogfood a lot — more in the next section.
• It is more polished than the free alternatives presented in this post. It is also cheaper than the Visual Studio paid versions.
• NCrunch is a fantastic and mature tool. I know many developers who are addicted to its lightning-fast Live Unit Testing feature. But to achieve such performance NCrunch requires certain constraints on the tests. As a result, adapting the NDepend test suite (15,000+ tests) would require many changes. This proved impracticable, unfortunately.

How do we use coverage?

Now that you have a good idea of the paid and free .NET coverage tools, let’s explain how we approach testing and coverage at NDepend. For us, coverage is an essential development tool that we continuously use. Indeed, it is one of our 4 Lines of Defense Toward Bug-Free Code.

The heatmap shown in the screenshot above helps a lot in pinpointing which code needs more tests. But our preferred usage of coverage is the actionable rule: Types that used to be 100% covered by tests should still be 100% covered. We have thousands of classes 100% covered.

Why We Aim for 100% Coverage

Several reasons drive that choice:

• When refactoring a class that was 100% covered, we treat any newly discovered gaps seriously. Often they unveil regression bugs, or at least flag scenarios we did not anticipate.
• When a class sits at 95%+, the last 5% of hard-to-test code often signals design flaws, because design and testability go hand in hand. So those gaps carry more risk and deserve the most testing.
• If we find a bug in code that is 100% tested, we can usually reproduce it with a new test rather than manually clicking through the app. Once fixed, that test stays in the suite so it won’t return.
• 100% coverage is part of our definition of done. The coverage rules above verify it as an objective fact.
• We also tag classes with a [FullCoveredAttribute] and check that they stay 100% covered, so the intent is explicit in the source.

Conclusion

In short, coverage is not enough. It is easy to write an integration test that exercises hundreds of classes without actually checking any results. It works for us because our code contains thousands of assertions that our 15K+ tests challenge more than 200 million times per run. Indeed, assertions are not just for test code — application code should contain many as well.

Of course, there are debates around 100% Code Coverage. Not all classes deserve 100% coverage, especially the ones bound to hard-to-test concerns like UI or network. Not all development shops agree to spend resources on achieving 100% coverage, and they do well. So I have genuinely explained what we do and why we do it this way.

Now it’s your turn to decide which coverage tool to use and how you will make the most of your coverage data!

Frequently Asked Questions

What is code coverage in C#?

Code coverage measures how much of your C# code your tests actually execute, usually expressed as a percentage of lines, branches, or methods. In short, it points out the code paths that no test touches.

What is a good code coverage percentage?

There is no universal number. Many teams aim for 70-80%, while some (like us) keep critical classes at 100%. However, high coverage with weak assertions still means little — coverage tells you what ran, not whether you checked the result.

What is the difference between line and branch coverage?

Line coverage counts which lines ran. Branch coverage, on the other hand, checks whether each path through a condition (the true and the false side of an if) ran. Therefore branch coverage is stricter and usually more revealing.

What is the best free .NET code coverage tool?

For CI and the command line, Coverlet paired with ReportGenerator is the go-to. Meanwhile, for coverage highlighted inside the IDE, Fine Code Coverage or Visual Studio 2026 (now free in Community) are excellent choices.

How do I get code coverage from dotnet test?

Run dotnet test --collect:"XPlat Code Coverage". Coverlet then writes a coverage.cobertura.xml file that you can convert into a readable HTML report with ReportGenerator.

Does code coverage measure test quality?

No. It only measures how much code your tests run, not whether they assert anything meaningful. So treat it as one signal among several, not a goal in itself.