Clojurians Log v2
kaocha
Hi,
we are using a standard lein test on our Jenkins CI.
Jenkins can handle junit xml files so we are using lein test2junit plugin to generates them.
I’ve tried to replace the default lein test runner with kaocha. It works great except for junit files generated by kaocha’s junit xml plugin
The problem is how kaocha generates test suites and test case xml nodes.
A test suite in lein test2junit is a namespace in the test directory
In kaocha junit xml a test suite is a different concept https://cljdoc.org/d/lambdaisland/kaocha/1.0.641/doc/3-configuration#test-suites
The default test suite is unit.
When I run our tests lein test2junit it generates this XML
<testsuite name="ns.a">
<testcase name="test-a"/>
<testcase name="test-b"/>
<testcase name="ns.b/test-a"/>
<system-out>
output from ns.a only
</system-out>
</testsuite>
<testsuite name="ns.b">
<testcase name="test-a"/>
<system-out>
output from ns.b only
</system-out>
</testsuite><testsuite name="unit">
<testcase name="ns.a/test-a"/>
<testcase name="ns.a/test-b"/>
<testcase name="ns.b/test-a"/>
<system-out>
squashed output from every testcase...
</system-out>
</testsuite>lein test2junit does?
@ondrs I already responded to you on Github. I recommend forking the plugin. If this is a common use case then I would also consider a pull request that makes this behavior opt-in.
@plexus thanks for the answer
I think we can introduce 2 more options for your junit-xml plugin
1/ to disable system-out in the XML completely
2/ to reformat output into test2junit format
with option 2 enabled, we will have to disable system-out as well because kaocha will capture it under different testsuite and we cannot trace it back
sounds good! Hard for me to comment on bullet points like that, but if you're serious about working on this then please start by writing up a proposal, starting from a problem statement (this is very important, it needs to be clear what the problem is we are addressing). Post it as a github issue and we can take it from there. Once we agree on the problem we're trying to solve I can help out by writing up where to look for things in the implementation.
In this case your problem statement should probably contain information about who/what will consume this xml, and how it behaves.