🐞 Duplicate test case names for test-template-invocation tests

[EPadronU]

What happened?

The current implementation for handling test-template-invocation tests, such as when the @RetryingTest annotation is used, automatically prepends the displayName of the parent test to the generated test case names. This results in duplicated and cluttered test case names within the Allure report, negatively impacting readability and usability.

This issue echoes concerns previously highlighted in Issue #831, where similar naming challenges were discussed.

Example code

@RetryingTest(maxAttempts = 3, name = "{displayName} [Attempt {index}]")
public void shouldWorkAsExpected() {
    Assertions.assertTrue(true);
}

Current Behavior

The Allure report currently generates names like:

• Should work as expected Should work as expected [Attempt 1]

This duplication detracts from the report’s clarity and makes navigation cumbersome.

Screenshots

• Logs:
  

• Allure Report:
  

Expected Behavior

The test case names in the Allure report should be concise, with unnecessary repetition removed, such as:

• Should work as expected [Attempt 1]

Screenshots

• Logs:
  

• Allure Report:
  

Proposed solution

To enhance the usability of the Allure reports, I propose introducing a configuration flag, such as allure.disableDisplayNamePrepend, that would allow users to opt-out of the automatic prepending of the displayName for test-template-invocation scenarios.

Implementation details

• The modification can be made within the AllureJunitPlatform.java class of the allure-junit-platform module. The relevant logic could be updated around this line to conditionally prepend the displayName based on the new configuration flag.

• If the allure.disableDisplayNamePrepend flag is enabled, the framework should bypass the prepending step, ensuring that only the concise, meaningful name specified in the @RetryingTest annotation is used.

Considerations

• While removing {displayName} entirely from the @RetryingTest annotation's name argument could fix the reports, it also impacts the clarity of test results in other contexts (such as IDEs or logs), the proposed flag would provide a balanced approach. It allows users the flexibility to opt-out of the current behavior without disrupting existing workflows.
• Another workaround is to introduce Allure.getLifecycle().updateTestCase(testResult -> testResult.setName(testResult.getTestCaseName())); in each test method. However, this approach is impractical as it risks being overlooked/forgotten, introduces unnecessary clutter, and compromises the clarity of the test code.

Final words

I am confident that this enhancement will significantly improve the Allure report's usability and interoperability.

Thank you for your attention to this matter and for considering the proposed improvement.

What Allure Integration are you using?

allure-junit5

What version of Allure Integration you are using?

2.29.0

What version of Allure Report you are using?

2.30.0

Code of Conduct

• I agree to follow this project's Code of Conduct