As I read through it remembered I’d seen some discussion on xunit comparability mentioned before, I searched the issues for xunit and found @pekkaklarck comment here:
This got me thinking that perhaps the better approach would be:
to create some listener files that output a tailored xunit file in the format that the target system expects
additional listener files to output various JSON formats
update the documentation that this is now the way to get integration with test systems
deprecate the --xunit in robot in favour of using the listener method
The idea being that the listener will collect the data needed from robot as it runs the test, output the needed xunit XML / JSON / other format file to the output directory, so for example if you needed to integrate with Jenkins you would download the Jenkins listener and add --listener Jenkins.py to your robot command and it would output a file jenkins.xunit.xml (or something like that) in the format that works best for Jenkins. This also means if you need to integrate with multiple test systems that expect xunit file formats that are incomparable it would be easily handled as you can add multiple --listener options to your command and each would output a different file.
I guess we’ll need a project location where the integration listeners are stored so people can easily find and download them, but that should be easy to solve.
Anyone have thoughts on this idea good / bad / could be improved?
I like your idea, even if I am not an user for xUnit formats (but we know if/when will need it ).
This, I think it is not needed, to deprecate, because the option --xunit could receive an argument for the listener (internal by name, external by file/path). This way we continue to have compatibility with previous versions, and add the new listener function. Another advantage, could be a specific xUnit preparation or arguments validation, when the external listener is used. This is a “standardized” method for listeners we know they are for xUnit.
).