[
https://issues.apache.org/jira/browse/SUREFIRE-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16980362#comment-16980362
]
Tibor Digana edited comment on SUREFIRE-1724 at 11/22/19 5:50 PM:
------------------------------------------------------------------
[~mpkorstanje]
We have to include this in the umbrella of Test List Processor. We have these
ambitions in 3.0 but the test list processor speaks about the file or test path
and run-order feature.
AFAIK Cucumber works with classes and the way how Surefire discovers the
classes should be satisfactory, or did I miss something?
You can specify the patter of the file/class. So if it is {{*Spec}} then it
should be easy.
Any spontaneous discovery by JUnit5 selectors may break some features.
Doing it in IsolatedClassLoader is feasible for the forkCount > 1 but you may
have noticed that we are reworking several implementations (TCP/IP interprocess
communication, Reports API to support future JUnit5 reports, Provider
interface) and these selectors would also require splitting Provider interface
in two at least.
You can maybe see that JUnit5 is one of our provider and we have older users
e.g. Karaf/Felix/OSGi who are waiting longer to fix the blocker issue which can
be perfectly fixed with new TCP/IP interprocess communication.
This way i want to say that we have given order of the tasks as the users
requests come to JIRA.
In the next step would be the event-based report interface because this is a
prerequisite of Provider API and it solves the current activities in
JUnit5/opentest4j.
After this we would better satisfy requirements (SUREFIRE-1535) for the TestNG
and we will better understand the communication protocol between Maven process
and subprocess with JSON. This effectivelly removes the IsolatedClassLoader in
Maven process and enables the subprocess to perform filtering of test file
within the same JVM where it would be executed and we solved the old issue
requested by the Arquillian. I guess that DiscoverySelectors may fit here as
well.
was (Author: tibor17):
[~mpkorstanje]
We have to include this in the umbrella of Test List Processor. We have these
ambitions in 3.0 but the test list processor speaks about the file or test path
and run-order feature.
AFAIK Cucumber works with classes and the way how Surefire discovers the
classes should be satisfactory, or did I miss something?
You can specify the patter of the file/class. So if it is {{*Spec}} then it
should be easy.
Any spontaneous discovery by JUnit5 selectors may break some features.
Doing it in IsolatedClassLoader is feasible for the forkCount > 1 but you may
have noticed that we are reworking several implementations (TCP/IP interprocess
communication, Reports API to support future JUnit5 reports, Provider
interface) and these selectors would also require splitting Provider interface
in two at least.
You can maybe see that JUnit5 is one of our users and we have older users e.g.
Karaf/Felix/OSGi who are waiting longer to fix the blocker issue which can be
perfectly fixed with new TCP/IP interprocess communication.
This way i want to say that we have given order of the tasks as the users
requests come to JIRA.
In the next step would be the event-based report interface because this is a
prerequisite of Provider API and it solves the current activities in
JUnit5/opentest4j.
After this we would better satisfy requirements (SUREFIRE-1535) for the TestNG
and we will better understand the communication protocol between Maven process
and subprocess with JSON. This effectivelly removes the IsolatedClassLoader in
Maven process and enables the subprocess to perform filtering of test file
within the same JVM where it would be executed and we solved the old issue
requested by the Arquillian. I guess that DiscoverySelectors may fit here as
well.
> Support JUnit Platform DiscoverySelectors
> ------------------------------------------
>
> Key: SUREFIRE-1724
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1724
> Project: Maven Surefire
> Issue Type: Improvement
> Reporter: M.P. Korstanje
> Priority: Major
>
> The JUnit Platform defines multiple
> [DiscoverySelectors|https://junit.org/junit5/docs/5.0.2/api/org/junit/platform/engine/DiscoverySelector.html]
> to discover tests in different locations. This allows TestEngines to
> discover tests in classes, the class path root, resource root, files, ect.
> Currently Surefire supports TestEngine implementations through the
> JUnitPlatformProvider. However the JUnitPlatformProvider only issues
> discovery requests for classes that have already been discovered by Surefire.
> Additionally if no tests were discovered by Surefire then no test discovery
> requests will be issued at all.
> This means that Surefire does not fully utilize the discovery capabilities of
> the JUnit Platform and makes it impossible to use the JUnitPlatformProvider
> for test frameworks that do not have class based tests such as Cucumber.
> To make Cucumber work at the very least the class path root discovery
> selector would have to be supported.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
