DEV Community

Cover image for I built a .NET test reporter to solve two problems I kept seeing in test automation
Harshad Lambate
Harshad Lambate

Posted on

I built a .NET test reporter to solve two problems I kept seeing in test automation

I built Ace Reports — a .NET test reporter with automatic API capture and flaky-test detection

I've been working on test automation for several years, and one thing I kept finding frustrating was that a test report would tell me that a test failed, but not enough about what actually happened during the failure.

So I built Ace Reports around two problems I wanted to solve:

1. Identify flaky tests and preserve their history

If a test fails and then passes on a retry, I don't want the report to simply show the final Passed result. I want to know that the test was flaky, how many attempts it took, and what happened during those attempts.

2. Don't make testers add reporting code to their tests

I don't want testers to have to modify their test scripts just to populate the report. Things like API requests/responses, retry information, execution details, and screenshots on failure should be captured automatically wherever possible.

The goal is that you write your tests normally, run them, and the report automatically contains the information needed to investigate failures.

Ace Reports generates a self-contained HTML report, with no reporting server required. It currently has adapters for xUnit, NUnit, MSTest, and Reqnroll.

The project is available on NuGet and is currently at v1.0.1.

I'd like to get feedback from people working with .NET test automation:

What information do you wish your test reports captured automatically that they currently don't?

I'm especially interested in feedback around API capture, flaky-test detection, retries, and report usability.

Website: https://harshadlambate.github.io/AceReportsWebsite/

Sample Report

Top comments (0)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.