Tibor17 commented on a change in pull request #499:
URL: https://github.com/apache/maven-surefire/pull/499#discussion_r836228298
##########
File path:
surefire-providers/surefire-junit4/src/main/java/org/apache/maven/surefire/junit4/JUnit4Provider.java
##########
@@ -432,7 +430,6 @@ private static boolean hasFilteredOutAllChildren(
Description description )
private Filter createMethodFilter()
{
- TestListResolver methodFilter = optionallyWildcardFilter( testResolver
);
- return methodFilter.isEmpty() || methodFilter.isWildcard() ? null :
new TestResolverFilter( methodFilter );
+ return testResolver != null && testResolver.hasMethodPatterns() ? new
TestResolverFilter( testResolver ) : null;
Review comment:
@slawekjaranowski
I know what you mean but the problem is that the expression
`methodFilter.isWildcard() != methodFilter.hasMethodPatterns()`
talks about implementation behavior.
The whole problem is that we adapt the tests for implementation behavior to
pass because we trust the current behavior more than the tests.
Maybe the wildcard was not very properly implemented. Maybe it was, I do not
remember, but if we remove some test or method we should compensate it with
such strong tests and assertions where we would prove your logical expression.
If `hasMethodPatterns()` is enough, why do not you write unit test asserting
`isWildcard() != hasMethodPatterns()` for wildcards. That's the reason why I
started the
[discussion](https://github.com/apache/maven-surefire/pull/499/files/d9d914eb773b95e5a935994a6a033b4870187237#r835288021).
The filter is useless and should be null or should not be used for wildcards
and empty method patterns.
Why should we slow down the JUnit or TestNG with wildcard filters or why
should we let the filtering mechanism to open some unknown bug?
```
tlr = new TestListResolver( "*#*" );
assertFalse( tlr.isWildcard() );
assertTrue( tlr.hasMethodPatterns() );
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
