Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding support for JUnit extensions used by the XRay plugin for Jira #13103

Open
PascalVaudrevange opened this issue Jan 4, 2025 · 1 comment
Labels
plugin: junitxml related to the junitxml builtin plugin type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature

Comments

@PascalVaudrevange
Copy link

PascalVaudrevange commented Jan 4, 2025

What's the problem this feature will solve?

The Xray plugin for Jira (https://docs.getxray.app/display/XRAY/Taking+advantage+of+JUnit+XML+reports) uses an extended JUnit format to store e.g. the test description and test evidence:

  • The test description is stored as text inside a property element with name="test_description": link to Xray documentation
  • The test evidence is stored as (base64-encoded) item Elements inside a property Element with name="test_evidence": link to Xray documentation

The current implementation of pytest's record_property() fixture does not allow for these use cases.

Describe the solution you'd like

I've started writing a plugin to address these issues: https://github.com/PascalVaudrevange/pytest-junit-xray-xml by rewriting the JUnit export and providing Xray-specific fixtures. It's currently work in progress (so e.g. the JUnit-family selection is not implemented yet) and has not been thoroughly tested yet.

Alternative Solutions

Alternatively, one could probably use NUnit export, but this would require NUnit support along the CI/CD chain - in my use case, this is not the case.

Additional context

I'm happy to write the plugin. With this feature request I'd like to

  • gauge whether there is enough interest to pursue this further
  • understand if this should be a plugin or whether there is interest in making this part of standard pytest (see next point)
  • I might misremember, but I think I saw a comment in one of the issues here that mentioned that there might be a case for moving the JUnit support from pytest itself into a plugin, so this might be another use case for the plugin above. But I might misremember.
@RonnyPfannschmidt
Copy link
Member

Im fairly sure i was in favor of moving junit into a plugin

As far as in aware nobody in core is currently using or interested in junitxnl

So having it be a plugin opens up opportunity gir evolving it by interested parties

@Zac-HD Zac-HD added type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature plugin: junitxml related to the junitxml builtin plugin labels Jan 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plugin: junitxml related to the junitxml builtin plugin type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Projects
None yet
Development

No branches or pull requests

3 participants