[JUnit Platform] Use EngineDiscoveryRequestResolver #2835
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2835 +/- ##
============================================
+ Coverage 84.80% 84.86% +0.06%
+ Complexity 2728 2719 -9
============================================
Files 331 334 +3
Lines 9428 9569 +141
Branches 902 932 +30
============================================
+ Hits 7995 8121 +126
- Misses 1111 1118 +7
- Partials 322 330 +8 ☔ View full report in Codecov by Sentry. |
mpkorstanje
force-pushed
the
junit-platform-refactor
branch
from
29ff69e
to
bd9ac67
Compare
|
The current implementation of the JUnit Platform Engine treats Cucumbers documentation consistently uses This will become a problem if/when we start to use the |
| "\n" + | ||
| "This is a work around for the limited JUnit 5 support in Maven and Gradle. " + | ||
| "Please request/upvote/sponsor/ect better support for JUnit 5 discovery selectors. " + | ||
| "For details see: https://github.com/cucumber/cucumber-jvm/pull/2498\n" + |
There was a problem hiding this comment.
This should also be interesting for you (if/when it gets merged):
gradle/gradle#29535
| class IsFeature implements Predicate<Resource> { | ||
| @Override | ||
| public boolean test(Resource resource) { | ||
| return resource.getUri().toString().endsWith(".feature"); |
There was a problem hiding this comment.
Wouldn't checking Resource.getName() suffice here?
There was a problem hiding this comment.
Good one. Cheers.
| sortedChildren.forEach(descriptor::removeChild); | ||
| sortedChildren.forEach(descriptor::addChild); |
There was a problem hiding this comment.
I wonder if we should introduce an TestDescriptor.orderChildren(UnaryOperator<TestDescriptor> orderer) method (or similar). We could also make use of that in Jupiter. 🤔
There was a problem hiding this comment.
That would be most useful! Though I'm not sure I understand the signature. Were you thinking of Comparator<TestDescriptor>?
There was a problem hiding this comment.
Sorry, I meant UnaryOperator<List<TestDescriptor>>. While a Comparator makes sense as well, in some cases (think Collections.shuffle) it's easier to return a new list. The implementation should verify that no elements were added or removed.
🤔 What's changed?
⚡️ What's your motivation?
Fully utilize the
EngineDiscoveryRequestResolverAPI to reduce our own complexity (junit-team/junit5#3705, junit-team/junit5#3718)🏷️ What kind of change is this?
♻️ Anything particular you want feedback on?
📋 Checklist: