Closed romain-gilles-ultra closed 2 months ago
If including explicitly set environment variables in the report is required/wanted, we could use forkEnv
which is what all non-local test targets use.
Hi @lefou I'm sorry but I don't get it :cry: What do you mean should I update/fix something in my PR? Sorry
Do you mean mapping the forkEnv
values into the <properties>
section
Yeah, IIUC, you tried to put as much as possible information into the JUnit report. And since it can contain env variable and the sbt report also adds these env variable, I assumed, you might want to have these variable in the report. So I was suggesting a way to access them. But it's not an request from my side.
Hi @lefou I give it a try tell me what you think about it :hugs:
@romain-gilles-ultra I just realized, that the JUnit XML contains "properties" but I thought of "env vars", which is a completely different thing. So I guess we should revert to your previous solution. Sorry about that.
I think I can keep the system props as the <properties>
section is dedicated to that
Hi @lefou I fact after checking the doc we can use properties to capture env variables values: https://github.com/testmoapp/junitxml?tab=readme-ov-file#properties-for-suites-and-cases
Properties can be included for suites and cases to record additional information, such as version numbers, environment variables or links to CI pipelines.
I think we can keep this version as it joins the environment variables with the system properties no?
We could/should keep the Java system properties, although I'm not 100 percent certain, that they will be accurate. Since we spawn a new Java process to run the tests, there is a change some system properties are different. It would be cool, if we could either return the actual used properties from the test run or write the report file from the test runner process. Both requires more work, so we can keep it for another PR.
Regarding the environment variables, I we want include them in the report, we should prefix them (e.g. with sys.env.
or something like that). Otherwise, collisions or shadowing can occur. We can defer to some later PR too, until there is a demand for it.
Hi @lefou Thanks for the feedback. What about I remove the property management and we keep it for another PR? I can prepare the code to use properties like:
def handleResults(
doneMsg: String,
results: Seq[TestResult],
ctx: Ctx.Env with Ctx.Dest,
testReportXml: Option[String],
props: Option[Map[String, String]] = None
): Result[(String, Seq[TestResult])] = {
testReportXml.foreach(fileName =>
genTestXmlReport(results, ctx.dest / fileName, props.getOrElse(Map.empty))
)
handleResults(doneMsg, results, Some(ctx))
}
But keep the way the properties are fed for another iteration
I can prepare the code to use properties ... But keep the way the properties are fed for another iteration
Sound good to me.
JUnit XML
Rework the JUnit XML reporting feature. After a couple of tests, the XML report output is not compliant with the "standard" I try to make it more compliant without breaking the great first solution! I took inspiration from the pseudo specification and SBT implementation. One important point is that Maven and SBT are producing one output file per
<testsuite>
a.k.a. per test (spec...) class while this solution (original) is producing one<testsuites>
output file for the entire module. The specification supports it. We should keep this approach.In this PR:
testLocal
TestModule
,ScalaJSModule
,ScalaNativeModule
Resources
Maven output
One output per test class:
target/surefire-reports/TEST-io.ultra.AppTest.xml
mill test output Examples vs SBT
UTest
ZIO test
sbt output:
scalatest
FreeSpec
sbt output:
FlatSpec
sbt output: