Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

testing: add -test.report flag for xunit/junit results #17542

Closed
techtonik opened this issue Oct 21, 2016 · 2 comments

Comments

Projects
None yet
3 participants
@techtonik
Copy link

commented Oct 21, 2016

The idea is to add -test.report=junit flag to go test, which will produce gotests.xml in current directory (borrowed from https://nose.readthedocs.io/en/latest/plugins/xunit.html#options).

This is an extension of #2981 (and this specific #2981 (comment) by @alberts).

Why xUnit/JUnit first and not JSON?

JSON is not a specification for testing, so services like AppVeyor can't support it.

Why write report to file instead of streaming it to the screen?

Because screen is for humans and report are for robots. It is very inconvenient to sacrifice one for another with pipe formatters like https://github.com/jstemmer/go-junit-report and https://github.com/tebeka/go2xunit because there is no tee on Windows.

@quentinmit

This comment has been minimized.

Copy link
Contributor

commented Oct 21, 2016

As already discussed in #2981, we're not going to directly generate JUnit or xUnit or any of these other formats. Our goal is to implement a single well-specified output format for Go, and you can then use whatever converter you want on that output. I don't understand why this makes it difficult to use AppVeyor?

There is a kernel of an interesting idea here, however, which is to support both structured output and human-readable output at the same time. That has been mentioned obliquely on #2981, but feel free to raise this request explicitly.

@quentinmit quentinmit closed this Oct 21, 2016

@techtonik

This comment has been minimized.

Copy link
Author

commented Oct 21, 2016

@quentinmit can you cite the exact message. #2981 is too long to find the answer for people coming here from search engine(s).

Problem with AppVeyor and Windows in general that there is no native tee command there, so directing output to file and to screen at the same time is tricky.

The output for user should be different than for build engine, and the problem with #2981 that it probably tries to kill that other bird. Another issues is that the request is about JSON format only, which bears the risk to provide a poor interface/API for extension to more common formats.

@golang golang locked and limited conversation to collaborators Oct 21, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.