Skip to content

NUnit XML results

Example file

Download an example file here: example_nunit_report.xml

Structure

See Test-Result-XML-Format for details on the NUnit file structure.

<test-run>

<test-run> will be read as a report with one or more containers(s).

  • id: stored as the platform
  • testcasecount: Ignored.
  • result,total, passed, failed, inconclusive, skipped: Ignored, the numbers will be counted with our own functions.
  • asserts: Ignored.
  • engine-version: stored as OS
  • clr-version: stored as build
  • start-time: combined with run-date and stored as date
  • run-date: combined with start-time and stored as date
  • end-time: Ignored.
  • duration: Will be calculated by our own function adding up the duration of all <test-case> elements.

<command-line>

The command line text will be converted to a container with a (result) per line.

<filter>

If a filter is present, a dummy container will be created to display the filters and their content.

<or>, <and>, <not>, <id>, <cat>

Included as results in the container for <filter>.

<test>, <class>, <method>

Also included as result in the container for <filter>.

  • re: Ignored.

<prop>

Also included as result in the container for <filter>.

  • name: Ignored.
  • re: Ignored.

<test-suite>

A <test-suite> will be read as a container with one or more result(s) or another container that can also contain one or more result(s). A <test-suite> can also hold one or more attachment(s).

  • type: stored as classification.
  • id: stored as description in combination with fullname.
  • name: stored as title.
  • fullname: stored as description together with id and used as title if name is not present.
  • classname: stored as classification, if type is not present.
  • testcasecount: Ignored.
  • runstate: If set, it will be added as json_data.
  • label: If set, it will be added as json_data.
  • site: Ignored.
  • start-time: Ignored.
  • end-time: Ignored.
  • asserts: Ignored.
  • result,total, passed, failed, inconclusive, skipped, inconclusive & duration: Ignored, the numbers will be counted with our own functions.

<environment>

  • framework-version: Ignored.
  • clr-version: stored as report build, if it was not test in the API call.
  • os-version: stored as report os, if it was not test in the API call.
  • platform: stored as report platform, if it was not test in the API call.
  • cwd: Stored as container title for the rest of the environment variables..
  • machine-name, user, user-domain, culture, uiculture & os-architecture: Are stored a result in the environment container, if set.

<settings>

If there are settings, the formatter will create a new settings container with every <setting> as a result.

<setting>

The title of the result will be converted to: setting.name: setting.value

  • name: Will be used in the title of the result.
  • value: Will be used in the title of the result.

<test-case>

<test-case> will be read as a result and may have one or more attachment(s).

  • id: stored as json_data.
  • name: stored as title.
  • fullname: stored as description and used as title, if name is not present.
  • methodname: stored as json_data.
  • classname: stored as json_data.
  • runstate: Ignored.
  • seed: stored as json_data.
  • result: stored as status:
    • /Passed/i = 'passed'
    • /Failed/i = 'failed'
    • /Inconclusive/i = 'unknown'
    • /Skipped/i = 'skipped'
  • label: stored as json_data.
  • site: stored as json_data.
  • duration: stored as duration.
  • start-time: stored as json_data.
  • end-time: stored as json_data.
  • asserts: stored as json_data.

<properties>

Properties are handled the same way as settings. A container is created with every <property> as result.

<property>

The title of the result will be converted to: property.name: property.value

  • name: Will be used in the title of the result.
  • value: Will be used in the title of the result.

<reason>

Reason will be used as description to the result.

<failure>

Failure message will be stored as exception_name to the result.

<assertions>

When set, all <assertion> elements will be included in the exception_description

<assertion>

Every assertion will be converted to text as follows:

RESULT: <message>
<stack-trace>
----
  • result: Will be user in the exception_description

<message>

CData is used to add more information to description.

<stack-trace>

Containing CData is stored as exception_backtrace.

<output>

Contained CData will be added to the exception_description of failures.

<attachments>

If a <test-suite> or <test-case> has attachments, the containing <attachment> will be checked to see if we have received a corresponding file.

More about attachments.

<attachment>

<filePath> and <description> are checked for their values.

<filePath>

The filepath is used to find the file expected in the given attachment[] parameter in the API call. In the search, all attachments are checked with the filepath.

Example:

filePath = 'C:\path\to\your\attachment.png'
attachedFileName = 'attachment.png' # Match!

<description>

The description content will be used as asset description when a matched file is found.