Allow ConsoleLauncher to redirect STDOUT and STDERR to files instead of the console
#3166
Comments
|
@tomwhoiscontrary Do you have a concrete proposal how this would be configured? Via new options on the |
|
Well, my first thought is that if there is some way i could do this myself (a plug-in sort of thing), then i could play around with it and come back with a more concrete suggestion. The simplest thing that would address my use case would be a flag to ConsoleLauncher like: I'm not very confident about the name. Sadly i can't think of any other tools which support this. Perhaps the methods in java.lang.ProcessBuilder are a precedent? |
|
I think we should have separate options for stdout and stderr. Taking |
|
That would be fine for me - as long as i can redirect both to the same file! |
|
Sure, I think we can make that work by checking if both are set to the same file. |
|
@tomwhoiscontrary Would you be interested in taking a stab at this? |
|
I am still interested in working on this! Just don't have a lot of time for it. I started by doing a bit of reading and thinking. Bits of the JDK where we should either capture output, or document that we can't capture output, etc:
Gradle captures output from tests, so it might be a good benchmark to try to do whatever Gradle does. I tried to find out how it does whatever it does, but the Gradle codebase is absolutely labyrinthine; i think the key point is DefaultStandardOutputRedirector, but i'm not sure. Also interesting is the RedirectStdOutAndErr JUnit rule they use in testing.
|
|
Output capturing is already implemented in JUnit (as report entries): https://junit.org/junit5/docs/current/user-guide/#running-tests-capturing-output I think we should try reusing that in some form but avoid the indirection of capturing it as strings. |
|
I am interested in working on this problem. I am new to open-source contribution but has experience of working in java. |
|
@ShwetaliShimangaud I have not worked on this at all, so please go ahead. |
collab? @ShwetaliShimangaud |
|
@marcphilipp should we care about thread-safety? |
|
I've tried using output capturing as a ReportEntry, I'm getting the report in the method |
|
Update: we can deactivate a This can help us deactivate our |
Add method registerMergedStandardStreams in StreamInterceptor to merge stdout and stderr so both can be intercepted in an stdout interceptor. This will keep the relative order for both outputs, which makes it easier to correlate error messages with the corresponding output. Add new configuration parameter junit.platform.output.capture.merge to merge stdout and stderr and publish it as STDOUT_REPORT_ENTRY_KEY. Issue: junit-team#3166
Add new CLI options --redirect-stdout and --redirect-stderr to redirect stdout and stderr to a file, if both are set to the same file, stdout and stderr will be merged so we can keep the relative order of messages. This makes it easier to correlate error messages with the corresponding output. Issue: junit-team#3166
Document the changes for the previous two commit in the 5.11.0-M1 release notes and in the user guide. Issue: junit-team#3166
Add method registerMergedStandardStreams in StreamInterceptor to merge stdout and stderr so both can be intercepted in an stdout interceptor. This will keep the relative order for both outputs, which makes it easier to correlate error messages with the corresponding output. Add new configuration parameter junit.platform.output.capture.merge to merge stdout and stderr and publish it as STDOUT_REPORT_ENTRY_KEY to all registered TestExecutionListener instances. Issue: junit-team#3166
Add new CLI options --redirect-stdout and --redirect-stderr to redirect stdout and stderr to a file, if both are set to the same file, stdout and stderr will be merged so we can keep the relative order of messages. This makes it easier to correlate error messages with the corresponding output. Issue: junit-team#3166
Document the changes for the previous two commit in the 5.11.0-M1 release notes and in the user guide. Issue: junit-team#3166
Document the changes for the previous two commit in the 5.11.0-M1 release notes and in the user guide. Issue: junit-team#3166
Add @API annotation to new methods. Issue: junit-team#3166
Add method registerMergedStandardStreams in StreamInterceptor to merge stdout and stderr so both can be intercepted in an stdout interceptor. This will keep the relative order for both outputs, which makes it easier to correlate error messages with the corresponding output. Add new configuration parameter junit.platform.output.capture.merge to merge stdout and stderr and publish it as STDOUT_REPORT_ENTRY_KEY to all registered TestExecutionListener instances. Issue: junit-team#3166
Add new CLI options --redirect-stdout and --redirect-stderr to redirect stdout and stderr to a file, if both are set to the same file, stdout and stderr will be merged so we can keep the relative order of messages. This makes it easier to correlate error messages with the corresponding output. Issue: junit-team#3166
Document the changes for the previous two commit in the 5.11.0-M1 release notes and in the user guide. Issue: junit-team#3166
Add @API annotation to new methods. Issue: junit-team#3166
sbrannen
changed the title
ConsoleLauncher to redirect STDOUT and STDERR to files instead of the console
|
My test suites are large, and write a lot of stuff to output as they go along (mostly from the code under test rather than the tests themselves). I run them using ConsoleLauncher. The tree report at the end of the run is useful. But the torrent of console output is usually not: it is very helpful to have output captured when diagnosing failures, but seeing reams out output for passing tests is not.
I believe that JUnit can capture standard output and error. It would be very useful if there was a flag i could give to ConsoleLauncher to tell it to do this, and write the results to one or more files, instead of the console. The simplest thing would be to write all output to a single file (whose contents would be the same as what i currently see in the console). Significantly more useful would to write the output of each test to its own file, to make it easier to find. Perhaps tests which write no output could not create files at all, not sure.
A potential quirk here is that much of this output is written using a logging framework (usually java.util.logging) with an appender which writes to standard output. It would be possible to configure logging differently in tests, but i would prefer not to have to do that - just capturing output as it is written with the default logging configuration is greatly preferable to me.
One thing that wouldn't be useful to me is separate files for standard output and standard error. There is not usually a huge semantic difference between the two, whereas the relative order of messages written across both is usually very important, and separating the files would discard that.
Is there already some way to do this? Would it be possible for me to write some sort of extension to do this, which i could use without modifying my test sources? If not, would this make a good feature?
The text was updated successfully, but these errors were encountered: