Open misiekstewa opened 5 years ago
I don't think that the xml reports that TestNG generates ever captured the sys out and sys error in the reports.
ping @cbeust @juherr WDYT ?
If possible, I think TestNG should have the same result than JUnit. But I don't know what could be the technical impacts
@juherr - I think it would be a challenge when trying to implement this for parallel execution, because the underlying PrintStream within System class dont seem to be thread safe.
Right, maybe the feature can be only activated when parallel is not activated.
Not a priority issue IMO.
I'd like to extend on this issue. I think the report, generated by org.testng.reporters.JUnitReportReporter
should at least show the output, previously sent to org.testng.Reporter
. This should be possible by writing the content of Reporter.getOutput(currentTestResult)
to the <system-out>
tag in the Report.
Compared to handling sysout and syserr, this sould be relatively easy to implement.
Thank you!
@krmahadevan May I ask you kindly, for feedback on my request? Implementing this would be a considerable help for my project. Thank you!
@UrsLange - I don't want to club your ask in this issue, because this issue talks about capturing the sys out
output, and you are asking for Reporter.log()
contents. Please open up a new issue for your ask and I will try to get to it.
@krmahadevan Thank you for your response. I created #2124 for the matter.
TestNG Version
6.14.3
Expected behavior
Inside the TEST-mytestname.xml when it's running with JUnit 4
Actual behavior
Inside the TEST-mytestname.xml when it's running with TestNG
Is the issue reproductible on runner?
Test case sample
I'm not sure if it's an issue or expected behaviour but when I'm running the same test with JUnit in the .xml report I'm able to see the system output, which is executed in static blocks before the test. So I mean everything which is appearing after:
but if I update annotations to TestNG annotations and update mu build.gradle file with
then standard output is visible in the console but it's not saved in the .xml report file.
If that is a bug (not only issue with bad configuration) then I'll try to implement some small test which will be reproducing this.