---
title: xUnit.net Integration with Mergify
description: Report your test results from xUnit.net to Mergify
---

This guide shows how to generate a JUnit report from your
[xUnit.net](https://xunit.net/) tests and upload it to **Test Engine** from
your CI workflow.

How you get the report depends on the version of xUnit.net your test projects
use: v2 projects run under `dotnet test`'s classic runner and take a JUnit
logger, while v3 projects ship a JUnit reporter of their own.

## Generate a JUnit report with xUnit.net

### xUnit.net v2

Add the JUnit logger to your test project:

```bash
dotnet add package JunitXml.TestLogger
```

Then run your tests with it:

```bash
dotnet test --logger "junit;LogFilePath=junit.xml"
```

`LogFilePath` is resolved relative to the directory holding your test project's
`.csproj`, not to the directory you run `dotnet test` from. If your test
project lives in a subdirectory, set the upload step's `report_path` to the
report's path from the repository root, such as `tests/Shop.Tests/junit.xml`.
With several test projects, each writes its own `junit.xml` next to its
`.csproj`.

### xUnit.net v3

On the .NET 10 SDK, xUnit.net v3 projects run on Microsoft.Testing.Platform,
which the JUnit logger above does not plug into. Use xUnit.net's own reporter
instead.

`dotnet test` runs Microsoft.Testing.Platform projects only once the
`global.json` at your repository root opts in:

```json
{
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}
```

Then run each test project with the reporter turned on:

```bash
dotnet test --project tests/Shop.Tests --results-directory test-results/Shop.Tests --report-xunit-junit --report-xunit-junit-filename junit.xml
```

This writes `test-results/Shop.Tests/junit.xml`.

Run this command once per test project, each with its own
`--results-directory`. When one `dotnet test` runs a whole solution, every
project writes to the same report file, and the file ends up holding the
tests of a single project.

## Update your CI workflow

The examples below use one v2 test project at the repository root, with the
report in `junit.xml`. With v3, run your projects with the command above and
upload `test-results/*/junit.xml` instead.

### GitHub Actions

> **Note:** your Mergify application key with the `ci` scope must be available to your CI as `MERGIFY_TOKEN`, as explained in the [CI setup guides](/ci-insights#ci-setup-guides).

Run the tests in a step with an `id`, and let the upload step decide the
job's result:

```yaml
- name: Run xUnit.net Tests
  id: tests
  continue-on-error: true
  run: dotnet test --logger "junit;LogFilePath=junit.xml"
```

```yaml
- name: Mergify CI Upload
  if: success() || failure()
  uses: mergifyio/gha-mergify-ci@v27
  with:
    token: ${{ secrets.MERGIFY_TOKEN }}
    report_path: junit.xml
    test_step_outcome: ${{ steps.tests.outcome }}
```

Key points:

- `if: success() || failure()`: runs the upload step even when the tests fail, so **Test Engine** gets the full report.
- `report_path: junit.xml`: where your test run writes the JUnit file. It must match the path your test configuration uses.
- `test_step_outcome: ${{ steps.tests.outcome }}`: passes the test step's outcome, so Mergify detects a runner that crashed while the JUnit report looks clean. Give your test step an `id` (here `tests`) and use it in `steps.<id>.outcome`.
- On pull requests from forks and from Dependabot, `MERGIFY_TOKEN` is empty and this step fails: skip it as shown in [Pull Requests Without the Secret](/ci-insights/setup/github-actions#pull-requests-without-the-secret).

If you use a job matrix in your workflow (e.g., to test across multiple versions), every leg reports the same job name, because GitHub Actions gives them all one `GITHUB_JOB`. Set the `job_name` input so **Test Engine** can tell the reports apart:

```yaml
jobs:
  example_matrix:
    strategy:
      matrix:
        version: [10, 12, 14]
```

Your upload step should look like:

```yaml
- name: Mergify CI Upload
  if: success() || failure()
  uses: mergifyio/gha-mergify-ci@v27
  with:
    job_name: example_matrix (${{ matrix.version }})
    token: ${{ secrets.MERGIFY_TOKEN }}
    report_path: junit.xml
    test_step_outcome: ${{ steps.tests.outcome }}
```

> **Note:** the job name is part of a test's identity, so a scheduled workflow has to report the same name as the job running those tests on your pull requests.

To benefit from Test Engine quarantine, you need to add `continue-on-error: true`
in your GitHub Actions step that executes your tests and generates the JUnit file.
The step running the `gha-mergify-ci` action then decides whether the job passes or fails,
taking quarantined tests into account.

You should also pass `test_step_outcome: ${{ steps.tests.outcome }}` to the step that runs
`mergifyio/gha-mergify-ci` (where `tests` is the `id` of your test runner step) to detect
silent failures where the test runner crashed but the JUnit report appears clean. Without
this input, a crash that produces a partial or empty report could be mistakenly treated as a
success.

With `continue-on-error: true`, the job's result comes from the upload step. On
pull requests from forks and from Dependabot, `MERGIFY_TOKEN` is empty and the
upload step has to be skipped: add the step that fails the job when the tests
failed and nothing was uploaded, as shown in
[pull requests without the secret](/ci-insights/setup/github-actions#pull-requests-without-the-secret).

### Buildkite

```yaml
steps:
  - label: "Run tests"
    command: <your test command>
    plugins:
      - mergifyio/mergify-ci#v8:
          action: junit-process
          report_path: junit.xml
```

Key points:

- The plugin runs in the `post-command` hook, so it uploads results **after** your tests finish, even if they fail.
- `report_path: junit.xml`: where your test run writes the JUnit file. It must match the path your test configuration uses.
- Silent failure detection is automatic: the plugin reads the step's exit code to detect a runner that crashed while the JUnit report looks clean.

If you use a build matrix in your pipeline, each variation reports its own step label as its job name, so the variations are already distinct. Set the `job_name` plugin property when the label is not the name you want **Test Engine** to file the reports under:

```yaml
steps:
  - label: "Flaky detection ({{matrix}})"
    matrix:
      - "3.10"
      - "3.11"
      - "3.12"
    command: <your test command>
    plugins:
      - mergifyio/mergify-ci#v8:
          action: junit-process
          job_name: "Tests ({{matrix}})"
          report_path: junit.xml
```

> **Note:** the job name is part of a test's identity, so a scheduled pipeline has to report the same name as the step running those tests on your pull requests.

> **Caution: keep the token out of the pipeline you upload.** Set `MERGIFY_TOKEN` in the environment of the agents running your steps: [Buildkite secrets](https://buildkite.com/docs/pipelines/security/secrets/buildkite-secrets), a secrets plugin backed by your own secrets store, or an agent `environment` hook that exports it. Do not put the token in the pipeline itself: `buildkite-agent pipeline upload` interpolates `${MERGIFY_TOKEN}` before the pipeline is stored, so a token written into an `env:` block is uploaded in plain text and stays readable in the Buildkite UI and in build history. The plugin's `token:` property carries it the same way.

When using the Buildkite plugin for Test Engine quarantine, the plugin automatically
detects test failures using the step's exit code. No extra configuration is needed.

The `mergifyio/mergify-ci` plugin runs in the `post-command` hook and reads
`BUILDKITE_COMMAND_EXIT_STATUS` to detect silent failures where the test runner
crashed but the JUnit report appears clean.

### Any CI (Mergify CLI)

Install the [Mergify CLI](/cli/usage) in your pipeline and export `MERGIFY_TOKEN`. Run `mergify ci junit-process` after your tests:

```bash
set -o pipefail
exit_code=0
dotnet test --logger "junit;LogFilePath=junit.xml" || exit_code=$?
mergify ci junit-process \
  --test-exit-code "$exit_code" \
  junit.xml
```

Key points:

- `MERGIFY_TOKEN`: export this environment variable with your Mergify application key so `junit-process` can authenticate to the API.
- `|| exit_code=$?`: CI shells run with `-e`, so a failing test command on its own line would end the script before the upload. This form keeps going and records the code.
- The script needs bash for `set -o pipefail`: on Jenkins, whose `sh` steps often run `dash`, start it with `#!/bin/bash`.
- `--test-exit-code "$exit_code"`: passes the test runner's exit code, so Mergify detects a runner that crashed while the JUnit report looks clean.
- `junit-process` runs last, so its status becomes the step's: `0` when every failure it found is quarantined, `1` when one is not.
- The branch quarantine is evaluated against is detected from your CI provider, falling back to the checked-out branch. Pass `--tests-target-branch <branch>` only to override it.

## Test names

With xUnit.net v2 and the JUnit logger, Test Engine names each test by its
class's full name, then a dot and its method: the fact `AddsAnItem` of the
class `Shop.Tests.CartTest` is reported as `Shop.Tests.CartTest.AddsAnItem`.
Each case of a theory is a test of its own, named after its arguments:
`Shop.Tests.CartTest.Positive(n: 1)`.

xUnit.net v3's reporter writes the class's full name into each test's name as
well, so names repeat the class: `Shop.Tests.CartTest.Shop.Tests.CartTest.AddsAnItem`.
These names are as stable as the v2 ones. Moving from v2 to v3 changes every
name, though, so your tests start new histories in Test Engine.

Renaming a namespace, a class or a method starts a new history for the tests
it holds. Tests with a `Skip` reason are reported as skipped.

## Verify and review in Test Engine

After pushing these changes:

1. Your CI workflow runs your xUnit.net tests.
2. The logger, or xUnit.net v3's reporter, writes the JUnit report.
3. Mergify uploads the report to Test Engine.

You can then review your test results, including any failures or flaky tests,
directly in the [Test Engine
dashboard](https://dashboard.mergify.com/test-engine/detection).

## Troubleshooting tips

<ul>
  <li>
    Zero tests ran with xUnit.net v3: `--logger` is an option of the classic runner. On
    Microsoft.Testing.Platform, the run fails without running any test. Use
    `--report-xunit-junit` instead.
  </li>

  <li>
    Tests missing with xUnit.net v3: if several test projects share a results directory, they
    overwrite each other's report. Give each project its own `--results-directory`.
  </li>

  <li>The CLI provides information about the upload. Check the logs in GitHub Actions.</li>
<li>File paths: Double-check that the output file matches the path used in `report_path`.</li>
<li>Permissions: Make sure the `MERGIFY_TOKEN` is valid and setup in your GitHub Actions secrets [as explained in the docs](/ci-insights/setup/github-actions#enabling-ci-insights-for-github-actions).</li>
<li>Workflow conditions: If your step is not running, confirm the if condition is actually triggered in your job.</li>
</ul>