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

Feature request: Support for test case properties #238

Open
dennisgrck opened this issue Jan 19, 2023 · 2 comments
Open

Feature request: Support for test case properties #238

dennisgrck opened this issue Jan 19, 2023 · 2 comments

Comments

@dennisgrck
Copy link

Hello there,

I would like to suggest adding support for properties on a test case level. As more and more tools such as CI and test management tools support test case properties, and as it can be very useful to include additional test attributes for tests, I think it would be a great addition for the Jest JUnit reporter.

This is also supported by various other test frameworks such as pytest or Playwright, as well as reporting and test management tools such as Testmo.

Properties for test cases

Here is an example of what test case properties look like in the resulting XML file. This is the same format as supported for the testsuite element, just below the testcase element:

<testcase name="testCase3" classname="Tests.Registration" time="3.441">
    <properties>
        <property name="priority" value="high" />
        <property name="language" value="english" />
        <property name="author" value="Adrian" />
        <property name="attachment" value="screenshots/dashboard.png" />
        <property name="attachment" value="screenshots/users.png" />

        <!-- Optional support for properties with text values -->
        <property name="description">
            This text describes the purpose of this test case and provides
            an overview of what the test does and how it works.
        </property>
    </properties>

    <!-- Optional output or error/failure/skipped -->
</testcase>

You can also find additional details on this format here as well as a full XML example file.

Possible API

I'm not sure what the best API would look like in Jest JUnit, but the API should ideally support multiple properties with the same name. Maybe something like this:

this.test.properties = [
    { name: 'author', value: 'Adrian' },
    { name: 'priority', value: 'high' },
    { name: 'attachment', value: 'screenshots/dashboard.png' },
    { name: 'attachment', value: 'screenshots/users.png' },
    { name: 'attachment', value: 'screenshots/error.png' },
];
@palmerj3
Copy link
Collaborator

Hey thanks for submitting a feature request!

This is something I also have wanted for a very long time, however it does not exist the junit spec we have always abided by.

We could make this an optional thing, perhaps.

If you weren't aware, jest-junit already supports test properties but it is at the test suite level not the test case level.

@dennisgrck
Copy link
Author

@palmerj3 Thanks for the feedback. Yes, the suggestion is for the test case level, as this is useful to include additional details for each test, e.g. to reference screenshots to explain test failures and to document test properties such as the severity etc. As many testing tools can read test case properties, this is helpful for Jest users so they can get better test reports in various tools.

I understand that this is not in the original Jenkins XSD, but there's no real 'standard' for the JUnit XML format, and various tools have extended the format specifically for test case properties. Jenkins is also just one tool that supports this format, and their XSD is quite outdated as I've found out. Just as an example, frameworks like pytest and Playwright also support this exact test case property format. I've done quite a bit of research and have tried to document the common use of JUnit-like XML files as used by various tools.

I agree that the properties should be optional. Either via an additional config option, or simply based on whether the developer has added any properties. E.g. if no properties have been added, the <properties> section would just be missing, so the file would be fully backward compatible with the previous behavior.

I hope this makes sense!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants