-
Notifications
You must be signed in to change notification settings - Fork 543
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
[SUREFIRE-2040] No tests executed with junit-platform-suite and -Dtest=TestSuite #494
Conversation
@slawekjaranowski Feel free to have a look. |
maven-surefire-plugin/src/site/apt/examples/junit-platform.apt.vm
Outdated
Show resolved
Hide resolved
TestListResolver filter = optionallyWildcardFilter( parameters.getTestRequest().getTestListResolver() ); | ||
if ( !filter.isEmpty() && !filter.isWildcard() ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it not the same?:
TestListResolver testListResolver = parameters.getTestRequest().getTestListResolver();
if ( testListResolver.hasMethodPatterns() )
...
if true IT test doesn't cover this if
with param <test>JUnit5Tests</test>
For such change we should add unit test in JUnitPlatformProviderTest
with assertions for filters ...
Another case you change logic here .. but all unit test still pass, looks like missing tests or assertions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@slawekjaranowski
No, it is not same. See the other Providers -> JUnit4Provider , JUnitCoreProvider and TestNGProvider
It is there sine 2015, i.e. 7 years.
We forgot to the same here? Just a mistake...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok,
public static TestListResolver optionallyWildcardFilter( TestListResolver resolver )
{
return resolver.hasMethodPatterns() ? resolver : WILDCARD;
}
public final boolean isWildcard()
{
return equals( WILDCARD );
}
so:
TestListResolver filter = optionallyWildcardFilter( resolver );
// this expression will always true - or I don't see something
!filter.isWildcard() == resolver.hasMethodPatterns()
and is it possible?
resolver.hasMethodPatterns() == true && resolver.isEmpty() == true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are again in the discussions with refactoring other providers. But this issue is about Junit5 provider. So my goal is not to make all these providers very different. I have made them similar in this PR through JunitPlatformProvider changes and nowhere else. I am not interested in others yet.
The optionallyWildcardFilter()
can be removed but the condition can be changed in the next PR, i.e. !filter.isEmpty() && !filter.isWildcard() && !filter.hasMethodPatterns()
. Here I am trying to make a fix and not to make providers too different in terms of filtering. Feel free to open a new PR after this and you can change all providers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@slawekjaranowski
If you would work on the change, pls remove the method getWildcard()
in TLR as well. It is not used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, does not matter how and what we change in given expression, condition - such change should impact on unit tests.
-
I suppose that some of unit tests or assertions are missing, so should be fixed to be sure what we want to achieve.
-
If we sure that unit tests cover in proper way - the change has no effect and is not needed.
Unit tests exist in JUnitPlatformProviderTest
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@slawekjaranowski
I guess JUnitPlatformProviderTest
has similar use case which we can copy and adapt, this may help. This could be done in advance, your right. Please help me and push a new commit with the test if you have some spare time. Yesterday and today I am supporting Olivier with testing on a demo project. I would like to cut the release, the jdk 18 GA will be released soon as well and we have jdk 18 related fixes.
Ah, i forgot, we may use the latest MPOM, do you have experiences with the latest version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Latest MPOM #491 ready and waiting for you 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand getTestListResolver()
returns TestListResolver
with informations based on -Dtest
param.
So please give me example like:
test=xxxx
then filters.contains or filters.notContains some of TestMethodFilter instance or another filter instance which should be added for given -Dtest
then I will can write proper unit tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand getTestListResolver() returns TestListResolver with informations based on -Dtest param.
It also has some form of merged patterns includes/excludes, includeFile/excludeFile.
If you remember SUREFIRE-1426 with ildefonso and Olivier, that's exactly the part of code which updated the merge logic.
test=xxxx then filters.contains or filters.notContains some of TestMethodFilter instance or another filter instance which should be added for given -Dtest
Yes, I think the same, it would be enough to test newFilters()
and verify the collection content. I found some example which would help you, and you can reuse it, see the test method onlyGroupsIsDeclared()
in the test JUnitPlatformProviderTest
.
93de677
to
088fad6
Compare
Remove of getWildcard #497 |
ok, go with it ... after build fix 😄 I will prepare change with removing method |
You can look at #499 |
@slawekjaranowski
|
I didn't touch this PR 😄 |
@slawekjaranowski |
ProviderParameters providerParameters = providerParametersMock(); | ||
TestListResolver testListResolver = new TestListResolver( "*.java" ); | ||
assertTrue( testListResolver.isWildcard() ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok *.java
is wildcard ...
but **/*.java
should be wildcard or not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are both the same in this case.
The TLR assumes wildcard path if not specified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what result will be of?
new TestListResolver( '**/*.java' ). isWildcard()
...latform/src/test/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProviderTest.java
Outdated
Show resolved
Hide resolved
...latform/src/test/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProviderTest.java
Outdated
Show resolved
Hide resolved
@slawekjaranowski |
Following this checklist to help us incorporate your contribution quickly and easily:
for the change (usually before you start working on it). Trivial changes like typos do not
require a JIRA issue. Your pull request should address just this issue, without
pulling in other changes.
[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles
,where you replace
SUREFIRE-XXX
with the appropriate JIRA issue. Best practiceis to use the JIRA issue title in the pull request title and in the first line of the
commit message.
mvn clean install
to make sure basic checks pass. A more thorough check willbe performed on your pull request automatically.
mvn -Prun-its clean install
).If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.
I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
In any other case, please file an Apache Individual Contributor License Agreement.