Ralph Weires created SUREFIRE-2152:
--------------------------------------
Summary: Allow to show name (not just index) of parameterized
tests in console output
Key: SUREFIRE-2152
URL: https://issues.apache.org/jira/browse/SUREFIRE-2152
Project: Maven Surefire
Issue Type: Bug
Components: JUnit 5.x support, Maven Surefire Plugin
Affects Versions: 3.0.0-M9
Reporter: Ralph Weires
When running parameterized tests with surefire (JUnit5 in my case), it can be
tough to easily figure out which exact instances have failed, based on the
console output. While I can - at least in some places in the console output
(see also SUREFIRE-2151) - see the invocation ID of a failing test, I would
generally also want to see the name of the failing parameters in question along
with that (i.e. a representation of the actual arguments of the invocation,
possibly customized by a developer with {_}@ParameterizedTest(name="..."){_})
Especially for parameterized tests with large amounts of invocations, and/or
where those actual arguments are only defined at runtime (e.g. via JUnit5
{_}@MethodSource{_}), it can be very cumbersome to identify which precise
instance caused a failure, based on the numeric invocation-ID alone.
I have tried the different configurations introduced in 3.0.0-M4 (i.e. the ones
described in
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#surefire-extensions-and-reports-configuration-for-displayname]
/ introduced with SUREFIRE-1546), but none of them seem to really change
anything regarding the console reporting.
So I would appreciate having the possibility (ideally with another
configuration flag) to include the name of templated-tests such as
_@ParameterizedTest_ (in addition to the invocation-ID) along when creating the
test-name. Note that I am not really interested in any _@DisplayName_
annotations (which is what SUREFIRE-1546 covered) - to me this is mainly about
making it as easy as possible for developers to quickly identify which
invocation caused a failure.
I did actually prepare a patched surefire version that we have in use for this
(albeit without a configuration flag to control this behavior, don't know how
to do that). If that's something worth sharing, I'm happy to create a PR for it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
