[
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817626#comment-16817626
]
Stig Rohde Døssing edited comment on SUREFIRE-1546 at 4/15/19 7:54 AM:
-----------------------------------------------------------------------
[~marcphilipp] Yes, you're right. I forgot the "name =" part for
ParameterizedTest. Other than that I think we wrote the same thing?
[~tibor17]
Maybe I'm being unclear.
{code}
What is obious from your code and listener console is the fact that DisplayName
annotation has bar({0}) but the console has displayName: a parameterized test
(bar(int)), type: TEST, source: MethodSource [...] How should I as Surefire
developer cope with the JUnit API in this case of parameterized tests?
{code}
Keep in mind that you get multiple invocations of executionStarted for each
ParameterizedTest. Let's say there are two invocations of the test. You then
get 3 invocations of executionStarted
{code}
executionStarted - { displayName: bar{{0}}, type: CONTAINER, source:
MethodSource [className = 'org.apache.surefire.stdout.corrupt.DemoTest',
methodName = 'bar'] } <-- ParameterizedTest container
executionStarted - { displayName: a parameterized test (bar(int)), type: TEST,
source: MethodSource [...] } <-- First parameter invocation,
executionFinished - { displayName: a parameterized test (bar(int)), type: TEST,
source: MethodSource [...] } <-- First parameter invocation
executionStarted - { displayName: a parameterized test (bar(int)), type: TEST,
source: MethodSource [...] } <-- Second parameter invocation
executionFinished - { displayName: a parameterized test (bar(int)), type: TEST,
source: MethodSource [...] } <-- Second parameter invocation
executionFinished - { displayName: bar{{0}}, type: CONTAINER, source:
MethodSource [...] } <-- ParameterizedTest container
{code}
The point is that you are allowed to name both the whole ParameterizedTest
package of tests, and also name each individual invocation. Surefire currently
only looks at the DisplayName of the individual invocations. I'm trying to get
across that Surefire should instead take the DisplayName of both the individual
invocation, and the DisplayNames of any CONTAINER-type TestIdentifiers into
account.
Just to outline how Surefire's handling of this could look, RunListenerAdapter
could keep a List<TestIdentifier> in a field.
{code}
class RunListenerAdapter implements TestExecutionListener {
private final List<TestIdentifier> inScopeTestIdentifiers = ...
public void testStarted(TestIdentifier testIdentifier) {
inScopeTestIdentifiers.add(testIdentifier);
}
public void testFinished(TestIdentifier testIdentifier, TestExecutionResult
testExecutionResult) {
if (isTest) {
//inScopeTestIdentifiers now contains any TestIdentifiers for started
tests/containers that haven't finished, i.e. the "parents" of this test
String resolvedMethodName = inScopeTestIdentifiers.stream()
.filter(id -> id.getSource instanceof
MethodSource && id.type == CONTAINER)
.map(id -> id.getDisplayName())
.collect(Collectors.joining(" > "));
//resolvedMethodName should now be "a parameterized test (bar(int))"
resovledMethodName = resolvedMethodName + " > " +
testIdentifier.getDisplayName; //Is now "a parameterized test (bar(int)) >
bar(15)"
}
inScopeTestIdentifiers.remove(inScopeTestIdentifiers.size() - 1)
}
}
{code}
[~marcphilipp] can probably confirm whether this is a reasonable way to handle
ParameterizedTest/RepeatedTest/other TestTemplates for a listener?
{quote}
Now me as developer of Surefire should be interested in the following call:
[...] and I expect that display would have the string from the DisplayName
annotation, i.e. bar(15) etc
{quote}
Yes, and you do get the name from the DisplayName annotation, but JUnit
delivers it in an earlier invocation of executionStarted. It isn't enough to
look at only the TestIdentifier for the test. The listener should also look at
the "parent" TestIdentifiers (any other tests that have started, but not
finished).
was (Author: srdo):
[~marcphilipp] Yes, you're right. I forgot the "name =" part for
ParameterizedTest. Other than that I think we wrote the same thing?
[~tibor17]
Maybe I'm being unclear.
{code}
What is obious from your code and listener console is the fact that DisplayName
annotation has bar({0}) but the console has displayName: a parameterized test
(bar(int)), type: TEST, source: MethodSource [...] How should I as Surefire
developer cope with the JUnit API in this case of parameterized tests?
{code}
Keep in mind that you get multiple invocations of executionStarted for each
ParameterizedTest. Let's say there are two invocations of the test. You then
get 3 invocations of executionStarted
{code}
executionStarted - { displayName: bar{{0}}, type: CONTAINER, source:
MethodSource [className = 'org.apache.surefire.stdout.corrupt.DemoTest',
methodName = 'bar'] } <-- ParameterizedTest container
executionStarted - { displayName: a parameterized test (bar(int)), type: TEST,
source: MethodSource [...] } <-- First parameter invocation,
executionFinished - { displayName: a parameterized test (bar(int)), type: TEST,
source: MethodSource [...] } <-- First parameter invocation
executionStarted - { displayName: a parameterized test (bar(int)), type: TEST,
source: MethodSource [...] } <-- Second parameter invocation
executionFinished - { displayName: a parameterized test (bar(int)), type: TEST,
source: MethodSource [...] } <-- Second parameter invocation
executionFinished - { displayName: bar{{0}}, type: CONTAINER, source:
MethodSource [...] } <-- ParameterizedTest container
{code}
The point is that you are allowed to name both the whole ParameterizedTest
package of tests, and also name each individual invocation. Surefire currently
only looks at the DisplayName of the individual invocations. I'm trying to get
across that Surefire should instead take the DisplayName of both the individual
invocation, and the DisplayNames of any CONTAINER-type TestIdentifiers into
account.
Just to outline how Surefire's handling of this could look, RunListenerAdapter
could keep a List<TestIdentifier> in a field.
{code}
class RunListenerAdapter implements TestExecutionListener {
private final List<TestIdentifier> inScopeTestIdentifiers = ...
public void testStarted(TestIdentifier testIdentifier) {
inScopeTestIdentifiers.add(testIdentifier);
}
public void testFinished(TestIdentifier testIdentifier, TestExecutionResult
testExecutionResult) {
if (isTest) {
String resolvedMethodName = inScopeTestIdentifiers.stream()
.filter(id -> id.getSource instanceof
MethodSource && id.type == CONTAINER)
.map(id -> id.getDisplayName())
.collect(Collectors.joining(" > "));
//resolvedMethodName should now be "a parameterized test (bar(int))"
resovledMethodName = resolvedMethodName + " > " +
testIdentifier.getDisplayName; //Is now "a parameterized test (bar(int)) >
bar(15)"
}
inScopeTestIdentifiers.remove(inScopeTestIdentifiers.size() - 1)
}
}
{code}
[~marcphilipp] can probably confirm whether this is a reasonable way to handle
ParameterizedTest/RepeatedTest/other TestTemplates for a listener?
{quote}
Now me as developer of Surefire should be interested in the following call:
[...] and I expect that display would have the string from the DisplayName
annotation, i.e. bar(15) etc
{quote}
Yes, and you do get the name from the DisplayName annotation, but JUnit
delivers it in an earlier invocation of executionStarted. It isn't enough to
look at only the TestIdentifier for the test. The listener should also look at
the "parent" TestIdentifiers (any other tests that have started, but not
finished).
> JUnit 5 runner does not honor JUnit 5 display names
> ---------------------------------------------------
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
> Affects Versions: 2.22.0
> Reporter: Romain Manni-Bucau
> Assignee: Tibor Digana
> Priority: Major
> Labels: junit5
> Fix For: 3.0.0-M4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the
> classname if any is defined. Seems last release doesn't support that feature
> of JUnit 5 making the console output and reports not the expected ones.
>
> Origin: https://github.com/junit-team/junit5/issues/990
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
