

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.Īnd it should be a deal breaker. If you have a Visual Studio Enterprise license, your life is good in a lot of ways.

You can have it paint your IDE, meaning it lets you actually visualize the coverage as you look at your code.You can select all of your tests or subsets of them.It reports coverage percentages at various granularities (e.g., assembly, class, etc.).But this is a nice, comprehensive option that requires very little additional work, assuming you have the correct version. You can read about this in more detail at the Microsoft documentation site. If you have the enterprise version, you can take advantage of this capability out of the box. It depends on your version of Visual Studio. NET ecosystem.īefore you gear up to start downloading things or breaking out your wallet, understand that you may already have this capability. So today, I’ll take you through some of your options in the. The result is an array of tools to choose from that help you see how well your test suite covers your codebase. It’s just a measure of whether or not the tests execute the code.) (Don’t confuse code coverage with an assessment of the quality of your tests, though. In just about any language and tech stack imaginable, you have ways to detect how thoroughly the unit test suite covers your codebase. They’ve automated code coverage detection. So developers have done what developers do. Well, as you can imagine, computing code coverage the way I just did would get pretty labor intensive.

For instance, code coverage analysis would tell us here, “Hey, you need to test the case where you pass a 0 to the method for y.” What Are Code Coverage Tools? So in the grossest of terms, that’s the “what.” As for the “why,” developers can use code coverage analysis to see holes in their testing efforts. Absent any other tests, no automated test ever executes that last line. Well, this test would cause the runtime to test the conditional and then to execute the return x/y statement, thus executing two-thirds of the method. Let’s also say that we wrote a single unit test, from which we invoked Divide(2, 1) and asserted that we should get back 2. Let’s say this was the only method in our codebase.
