[!IMPORTANT]
Development of v4.x and subsequent versions of the Junit logger is moved to the testlogger repository. Kindly report any new issues or contribute your patches in that repo.

JUnit Test Logger

JUnit xml report extension for Visual Studio Test Platform.

Packages

Logger	Stable Package	Pre-release Package
JUnit

If you're looking for Nunit, Xunit or appveyor loggers, visit following repositories:

• https://github.com/spekt/nunit.testlogger
• https://github.com/spekt/xunit.testlogger
• https://github.com/spekt/appveyor.testlogger

Usage

The JUnit Test Logger generates xml reports in the Ant Junit Format, which the JUnit 5 repository refers to as the de-facto standard. While the generated xml complies with that schema, it does not contain values in every case. For example, the logger currently does not log any properties. Please refer to a sample file to see an example. If you find that the format is missing data required by your CI/CD system, please open an issue or PR.

To use the logger, follow these steps:

1. Add a reference to the JUnit Logger nuget package in test project

2. Use the following command line in tests

   > dotnet test --logger:junit
   

3. Test results are generated in the TestResults directory relative to the test.csproj

A path for the report file can be specified as follows:

> dotnet test --logger:"junit;LogFilePath=test-result.xml"

test-result.xml will be generated in the same directory as test.csproj.

Note: the arguments to --logger should be in quotes since ; is treated as a command delimiter in shell.

All common options to the logger are documented in the wiki. E.g. token expansion for {assembly} or {framework} in result file. If you are writing multiple files to the same directory or testing multiple frameworks, these options can prevent test logs from over-writing each other.

Customizing Junit XML Contents

There are several options to customize how the junit xml is populated. These options exist to provide additional control over the xml file so that the logged test results can be optimized for different CI/CD systems.

Platform Specific Recommendations:

• GitLab CI/CD Recommendation
• Jenkins Recommendation
• CircleCI Recommendation

After the logger name, command line arguments are provided as key/value pairs with the following general format. Note the quotes are required and key names are case sensitive.

> dotnet test --test-adapter-path:. --logger:"junit;key1=value1;key2=value2"

MethodFormat

This option alters the testcase name attribute. By default, this contains only the method. Class, will add the class to the name. Full, will add the assembly/namespace/class to the method.

We recommend this option for GitLab users.

Allowed Values

• MethodFormat=Default
• MethodFormat=Class
• MethodFormat=Full

FailureBodyFormat

When set to default, the body of a failure element will contain only the exception which is captured by vstest. Verbose will prepend the body with 'Expected X, Actual Y' similar to how it is displayed in the standard test output. 'Expected X, Actual Y' are normally only contained in the failure message. Additionally, Verbose will include standard output from the test in the failure message.

We recommend this option for GitLab and CircleCI users.

Allowed Values

• FailureBodyFormat=Default
• FailureBodyFormat=Verbose

License

MIT