Support .NET unit test results directly
04.03.2020 Update / Why is this still in the backlog?
For now an update has been made to the documentation for JUnit reports about how to convert some reports generated by dotnet test
to a format that the existing features can parse so this item has been put into the Backlog. When there is additional need for native parsing or new use cases that support the need for parsing directly we will reconsider this item.
Problem to solve
Visual Studio generates unit test results in a .trx file or Nuget package.
We only support reading JUnit style test results, which means users have to manually convert using third party tools like https://github.com/gfoidl/trx2junit for .trx files or JunitXml.TestLogger.
This is less than ideal and requires users to convert the output of their test cases.
Intended users
Software development teams who want to see unit test results output in .trx format. This is a feature that directly impacts the day to day workflow of the developer Sasha who is working in Visual Studio.
Further details
This item contributes to the multi-platform vision of the CI/CD section and making Windows Developers first class citizens in GitLab.
Use Cases
- When a .trx file is available parse the results to appear in the merge request widget
- When a .trx file is available parse the results to show failures in the job view.
- When a .trx file has
<StdOut>
entries add the contents to the view including<ErrorInfo>
and<Output>
so I can see extra information about skipped tests.
Proposal
We should consider supporting the .NET TRX file format along with JUnit. There are existing solutions out there to do this parsing like trx2junit so an open source option may exist that converts this into a format existing functionality can use without further parsing support.
Permissions and Security
There are no known permissions or security changes associated with this.
Documentation
- Update to document how projects with .trx files should be setup to display unit test results natively.
Testing
- Test for performance of massive .trx files and/or account for error states if the file cannot load
- Test for bad input files and create an error state for that.
What does success look like, and how can we measure that?
- This will be successful if we see the page views of the jobs>tests tab increase by xx% (based on some percentage of projects on GitLab being c# or .net and then 10% of customers using this feature in the first month).
Links / references
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.