ASP.NET Core Code Coverage Reports On Azure DevOps
We take things a step further by demonstrating how to generate ASP.NET coverage reports on Azure DevOps.
Join the DZone community and get the full member experience.Join For Free
After making ASP.NET Core code coverage reports work on a local box, I took it a step further and made code coverage reports available also on Azure DevOps. This blog post shows how to generate code coverage reports for .NET and ASP.NET Core applications on Azure DevOps.
This blog post expects that there is .NET or ASP.NET Core project with unit tests and code coverage reports. It also assumes the existence of an Azure DevOps build pipeline that is connected to a source code repository. It's covered well on a previous blog post about automated testing, "Code coverage reports for ASP.NET Core."
Here is the build pipeline of one of my sample applications. I highlighted the report generator task on the screenshot. Notice also date based versioning task in the pipeline.
The report generator is run after tests because before the tests we didn't have test results or code coverage data.
Configuring Unit Tests
Most of the important work is done when unit tests are run. This is why we need to configure the test task first. Here is an example. We configure a unit test task that runs unit tests, gathers code coverage information, and saves the results to a build server disk. The results are XML files we need as an input for code coverage reports.
Here is the arguments block as text for copy and paste. It must be all one line with no line breaks in Arguments field of test task.
--configuration $(BuildConfiguration) /p:CollectCoverage=true /p:CoverletOutputFormat=cobertura /p:CoverletOutput=$(Build.SourcesDirectory)\TestResults\Coverage\
Run build to see if the test task succeeds and there are no errors and warnings.
Adding Code Coverage Reports
For code coverage reports we take the free ReportGenerator task by Daniel Palme from Visual Studio Marketplace. If you also need local code coverage reports then check out the ReportGenerator project from GitHub.
If an organization under a build pipeline that belongs doesn't have this task yet, then the task is first added to the organization and then it can be added to the build pipeline. Here is how to configure the ReportGenerator task.
The report types field specifies what type of reports we want. Here I asked for inline HTML, especially for Azure Pipelines and Cobertura. This is how I got reporting to work.
If you notice testing framework assemblies and namespaces (in my case xUnit) in code coverage reports, then add set Assembly filter property of ReportGenerator task
to: -xunit*.*. Using similar patterns, it's possible to leave out also other unwanted assemblies.
Save the changes to a build pipeline and run it to make sure all the steps succeed and that there are also no warnings by the unit tests or report generator task.
Viewing Code Coverage Reports
If all the steps in pipeline succeeded then there will be a new link to code coverage reports in the header of the pipeline run (in red rectangle). It is shown there automatically if code coverage information is published correctly.
When clicking on this link we can see a full code coverage report. We stay in the Azure DevOps environment, in the same view. Links shown in the report just work with Azure DevOps environment.
The report is interactive and we can click on class names to see more specific details about code coverage.
Reports like this are generated every time our build pipeline is run. If we make a build pipeline run on every commit to code repository, then we get code coverage reports for every build automatically.
We were already able to run code coverage reports on local boxes. Now we took it a step further and added code coverage reports to the Azure DevOps build pipeline. This way we make code coverage reports available for all commits and so those who don't bother to check reports locally can go and see their result on the build server.
Published at DZone with permission of Gunnar Peipman, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.