xUnit

To use Captain with xUnit, you need to configure your test suite to output test results to a file and then tell Captain where to find those test results.

Getting started

xUnit does not natively produce a test results artifact that Captain can parse. To integrate, you'll need to install XunitXml.TestLogger. Once you have XunitXml.TestLogger installed and configured, configure Captain by creating a .captain/config.yml file in the root directory of your repository:

test-suites:
  your-project-xunit:
    command: dotnet test --logger "xunit;LogFileName=xunit.xml" --results-directory "tmp"
    results:
      path: tmp/xunit.xml

You can change your-project-xunit to any name you like, but we typically recommend using the name of your project followed by a dash followed by xunit. The command is the command you already use to run your test suite. Captain will invoke this command to run your tests. The example above shows what you might use if you use dotnet test and want to store test results in tmp/xunit.xml.

Once Captain is configured, you can run captain run your-project-xunit --print-summary. If you see your typical test output following by a captain block like this:

--------------------------------------------------------------------------------
----------------------------------- Captain ------------------------------------
--------------------------------------------------------------------------------

then you've configured everything correctly! You can now supercharge your test framework's capabilities. See below for configuring each of Captain's features.

Exposing file information

By default, dotnet test does not provide file information to the logger, which means that it is also not exposed in Captain's UI.

To expose file information, add --configuration Debug to the end of your test command, and make the following configuration changes:

In your .runsettings file, which can be passed to dotnet test with the --settings flag:

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <RunConfiguration>
    <!-- existing configuration might be here -->
    <CollectSourceInformation>true</CollectSourceInformation>
  </RunConfiguration>
</RunSettings>

In your Directory.Build.props file:

<Project>
  <!-- existing configuration might be here -->
  <PropertyGroup Condition="'$(Configuration)' == 'Debug'">
    <DebugType>embedded</DebugType>
    <DebugSymbols>true</DebugSymbols>
  </PropertyGroup>
</Project>

Making those changes will ensure that file and line information for test are exposed as part of Captain's results.

Quarantining Tests

Traditionally, you might mark a test as pending or skipped to triage flaky or failing tests. With Captain, you can quarantine them instead. When only quarantined tests fail, Captain will still report your build as successful and exit with a 0 exit code. Unlike skipped tests, quarantined tests will continue to run, so you can still view their failure messages and see how frequently they are failing.

You can quarantine tests in OSS mode with captain add quarantine like so:

captain add quarantine your-project-xunit \
  --assembly xunit2.dll \
  --description "xunit2.UnitTest1.PassingTest"

See the identifying tests section of this page for more information on finding the assembly and description, and see the OSS quarantining guide for more information on managing quarantined tests in OSS mode.

Retrying Tests

You can configure Captain to automatically retry failed tests to help you determine if failing tests are flaky or are genuinely failing. To configure retries, update your .captain/config.yml file like so:

test-suites:
  your-project-xunit:
    command: dotnet test --logger "xunit;LogFileName=xunit.xml" --results-directory "tmp"
    results:
      path: tmp/xunit.xml
    output:
      print-summary: true
      reporters:
        rwx-v1-json: tmp/results.json
    retries:
      attempts: 2
      command: dotnet test --logger "xunit;LogFileName=xunit.xml" --results-directory "tmp" --filter '{{ filter }}'

Once configured, Captain will invoke your original test command, check for any failures, and retry your tests however many times you've specified (in this example, two additional times) by templating the failures into the command specified by retries.command. The output.print-summary option is not required, but we've added it for convenience in understanding the overall results after the retries have been factored in.

Partitioning

Unfortunately, due to limitations in xUnit, partitioning is not supported.

Identifying Tests

Captain uses framework specific "identity recipes" to identify the tests in your suite. These recipes are order dependent components extracted from native test framework output.

We use this identity to track the executions of a test over the course of their lifetime in your suite. This enables us to do things like flake detection, quarantining, and retries.

For xUnit, Captain constructs the identity by parsing out the assembly and description attributes.