Coverage reports in C# with Cobertura

In the last contract I completed, we were building WebAPI microservices in C#, and part of our build process was to run all of our XUnit (and, depending on who originally wrote the microservice, maybe NUnit) tests and use SonarCloud to produce a pretty amazingly specific coverage report that highlighted every source file's test status, line-by-line.

I've got a personal project in C#, have been spending time recently writing tests for it, and wondered if I could pull off the same level of coverage testing.

Turns out I can! Exactly the same!

Install by adding a ref to the coverlet collector to your testing proj:

dotnet add package coverlet.collector

Then run the test with this:

dotnet test --collect:"XPlat Code Coverage"

After the above command is run, a coverage.cobertura.xml file containing the results will be published to the TestResults directory as an attachment.

And sure enough, there's a new folder with every run in my C:\path\to\app\MyTestingProjectFolder\TestResults folder. The cobertura file is in painfully named folders like 946f0f00-2eec-4cef-b734-e683d4e258aa, but open the latest and you can see the XML.

Now the XML isn't very interesting.

<coverage line-rate="0.4882" branch-rate="0.465" version="1.9" timestamp="1745620667" lines-covered="1101" lines-valid="2255" branches-covered="299" branches-valid="643">
    <sources>
        <source>C:\path\to\app\MyApp\</source>
    </sources>
    <packages>
        <package name="MyAppPackage" line-rate="0.4882" branch-rate="0.465" complexity="734">
    <classes>
        <class name="Program" filename="Program.cs" line-rate="0" branch-rate="1" complexity="2">
    <methods>
        <method name="<Main>$" signature="(System.String[])" line-rate="0" branch-rate="1" complexity="1">
            <lines>
                <line number="16" hits="0" branch="False"/>
                <line number="20" hits="0" branch="False"/>
            </lines>
    </method>
<!-- ... -->

You have to turn that into a more interesting report.

This Stackoverflow answer explains how:

This tool quickly generate Html reports from coverage file. Works quite well and does not require complex activities, can be easily included in the build process.

From the README:

Install:

dotnet tool install -g dotnet-reportgenerator-globaltool

Run:

reportgenerator [options]

which, in my case, if I'm already in the same folder as the coverage.cobertura.xml file, looks like this:

reportgenerator -reports:".\coverage.cobertura.xml" -targetdir:"coveragereport" -reporttypes:Html

... which, because we said so in the options, creates a folder named coveragereport in the same dir, and within that are two html files that are identical except for their file extensions, index.htm and index.html. Far be it for a Microsoft-adjacent tool to stop producing three-letter file extensions.

And then that report looks incredible:

I have no idea why I redacted so much of that. Also note this is running against a very early stage piece of code. This coverage is obviously horrendous. But the coverage report isn't!

Labels: testing, windows

From "Amazon now has a ‘Get book’ button in its iOS Kindle app" on theverge.com:

Apple has appealed the decision, but is also complying with it in the interim, prompting several companies to announce app updates making it easier for users to pay for subscriptions and services. That now includes Amazon’s iOS Kindle app. Contrary to prior limitations, there is now a prominent orange “Get book” button on Kindle app’s book listings.

I just tried. It's there, and, though obviously easy in retrospect, the implementation surprised me:

Kindle iOS kicked me to Safari, which I keep in private mode, and the "Buy with one click" button is activated.

Okay, well shucks. Upon further review, apparently I don't usually pay much attention to that button, because it's always active, even if you're not logged in. Click it and it asks you to sign in.

But I wouldn't expect that to last long. Right now it looks like Amazon is only adding ref_=rekindleDP&nodl=0 to the URL, but they could add a unique, one-use GUID to the link and, with only a little risk to themselves (oh no! we gave away 200k worth of bytes to the wrong person!), make the button "live" immediately.

Adding a one-use, unique "buy now token" would make it easier to buy using Kindle than Apple's own Books. I click buy in Kindle, I click a "buy now!" button in the browser that's opened (no Touch or Face ID required), and a universal link sends me right back to Kindle.

And this would change our relationship with the web on our phones by merging apps and the web in ways I didn't really picture before. Now, Amazon knows where you were when you considered buying a book. They can do an okay job of fingerprinting you, not that they couldn't with you signed in within the app, but the extra data doesn't hurt. And, app review psychosis aside, there's no way for Apple to protect you beyond the way they protect any other surfer on Safari. (And with other default web browsers now on iOS, they can't always even do that.)

This is a pretty significant wall breaking down in the garden. I'm still tempted to think it's a huge positive for devs and users, but watching the platform regain its equilibrium will be fascinating.

That said, I feel like universal links are about to get overhauled.

Apple might soon say...

We'll let you out of iOS, but we're not letting you back in.

Ugh. Tim Apple strikes again.

(Though I haven't heard of them changing the rules there yet. You think Tim Apple's Apple (vs. Phil's Apple) would've had those universal link rule changes in the license already.)