The XUnit action in Continua is a wrapper around the XUnit.Runner.Console.exe command line. If you're having trouble using the XUnit action, please refer to the Command Line Reference.
The XUnit action can be used to run automated unit tests.
A friendly name for this action (will be displayed in the actions workflow area).
Determines if this action will be run within the relevant stage.
The path and file name of the test output. This path is relative to the workspace and the file must end in .xml (it will be appended if not). Leave blank to use the name of the first assembly. [-xml]
The file names or patterns to match assembly files to test.
Tick this to automatically install XUnit on the agent using NuGet. Additional fields will be shown allowing you to enter the "Platform" and installation folder "Install Xunit To". A new NuGet tab will also be displayed with options for the NuGet command line.
The version of XUnit to use to run the tests. Choose Custom if the version is not listed - if you are installing using NuGet then a "XUnit Runner Version" field will be displayed for you to enter the version to install.
Visible only if the "Install XUnit on agent using NuGet" is ticked.
The XUnit Runner Version.
When not installing using NuGet, the "Using" drop down is populated with any property collector whose namespace matches the pattern defined by the XUnit action. The pattern for this action is ^XUnit\..*
The default property collector will search the environment PATH for "xunit.console.exe". If you create a property collector for this action, make sure you select the Path Finder PlugIn type and give it a name that will match the pattern above in blue. Example names listed here, search the table's Plugin column for "XUnit".
For more in-depth explanations on property collectors see Property Collectors.
Alternatively, you can select the Custom option from the Using drop down list and specify a path in the resulting input field that will be displayed. Please read Why it's a good idea to use a property collector before using this option.
The folder NuGet should install XUnit to.
A list of package sources to install the XUnit package from. Optional. You can separate multiple sources with semi-colons.
Optionally install prerelease versions of the XUnit package.
Optionally attempt to source the XUnit package from the NuGet machine cache.
The platform which you are installing XUnit for. Choose Default to install the x86 version on 32-bit Windows or the x64 version on 64bit Windows. Choose XUnit.x86 to install the 32bit version on 64bit Windows.
The targeted XUnit executable to run the tests.
The Using drop down is populated by any property collector properties whose namespace matches the pattern defined by the NuGet action. The pattern for this action is ^NuGet\..*
. The default property collector searches the environment path for "NuGet.exe".
If you create a property collector for this action, make sure you select the Path Finder PlugIn type and give it a name that will match the pattern above in blue.
For more in-depth explanations on property collectors see Property Collectors.
Alternatively, you can select the Custom option from the Using drop down list and specify a path in the resulting input field that will be displayed. Please read Why it's a good idea to use a property collector before using this option.
Only run tests with any of the matching name/value traits. One per line. [-trait]
Only run any of the given test methods. One per line. Each method can be fully specified or use a wildcard. i.e. 'MyNamespace.MyClass.MyTestMethod' or '*.MyTestMethod'. [-method]
Only run any of the given test classes. One class per line. Each class should be fully specified. i.e. 'MyNamespace.MyClass. [-class]
Only run any of the given test namespaces. One per line. i.e. 'MyNamespace.MySubNamespace. [-namespace]
Do not run tests with any of the matching name/value traits. One per line. [-notraits]
Do not run any of the given test method. One per line. Each method can be fully specified or use a wildcard. i.e. 'MyNamespace.MyClass.MyTestMethod' or '*.MyTestMethod'. [-nomethod]
Do not run any of the given test classes. One class per line. Each class should be fully specified i.e. 'MyNamespace.MyClass'. [-noclass]
Do not run any of the given test namespaces. One per line. 'MyNamespace.MySubNamespace'. [-nonamespace]
If this is ticked, skipped tests are converted into failures. [-failskips]
If this is ticked, it stops on first test failure. [-stoponfail]
The level of parallelism. [-parallel]
The amount of information detail to display in the build log. [–quiet | -verbose]
Not visible if the 'Logging Level' field is set to Quiet'.
If this is ticked, it enables diagnostic messages for all test assemblies. [-diagnostics]
Tick this to cause the build to fail if any tests fail.
Tick this to cause the build to fail if an error occurred while running any test.
How long to wait for the action to finish running before timing out. Leaving this blank (or zero) will default to 86400 seconds (24 hours).
Tick to continue build on failure marking the action with a warning status.
If this is ticked, any warnings logged will not mark the action with a warning status.
Multiple environment variables can be defined - one per line. These are set before the command line is run.
If this is ticked, environment variable values are written to the build log.
Tick this checkbox to set up a list of new environment variables prefixed with 'ContinuaCI.' for all current system expression objects and variables.
This checkbox is visible only if the 'Generate system environment variables' checkbox is ticked.
If this is ticked, the values of any variables marked as sensitive will be masked with **** when setting system environment variables. Clear this to expose the values.