[
https://issues.apache.org/jira/browse/SUREFIRE-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981247#comment-16981247
]
M.P. Korstanje edited comment on SUREFIRE-1724 at 11/25/19 2:21 AM:
--------------------------------------------------------------------
> Why you use two providers? You added junit5 api to your POM dependencies, so
> it will be junit5 provider.
Demonstration purposes. I wanted to show how the API would work with a provider
that didn't implement discovery and with one that did. The important bit here
is that the JUnit4 Provider falls back to the test classes provided by surefire
and that JUnitPlatform Provider does it's own discovery.
> Since {{discoverTestsInFork}} returns multiple classes, it woun't be verry
> effective forking process because the loaded classes must be executed in the
> same fork jvm. Another alternative is to use isolated CL in plugin and
> discover them there.
That would be more efficient. We may have to take some care and use separate
launchers for discovery and execution though.
> Why you have to {{selectClasspathRoots}} if DiscoverySelectors already exist
> on the classpath? They are not found by SPI?
Indeed they are not load via SPI. The JUnit platform uses a builder pattern to
create a discovery request. There is a nicely comprehensive example here:
[https://junit.org/junit5/docs/5.0.0/api/org/junit/platform/launcher/core/LauncherDiscoveryRequestBuilder.html]
The discovery request is executed by all available TestEngine implementations.
The test engine implementations are loaded via SPI. The test engines then
query the discovery request for selectors that they implement and they use
those selectors to discover tests.
was (Author: mpkorstanje):
> Why you use two providers? You added junit5 api to your POM dependencies, so
> it will be junit5 provider.
Demonstration purposes. I wanted to show how the API would work with a provider
that didn't implement discovery and with one that did. The important bit here
is that the JUnit4 Provider falls back to the test classes provided by surefire
and that JUnitPlatform Provider does it's own discovery.
> Since {{discoverTestsInFork}} returns multiple classes, it woun't be verry
> effective forking process because the loaded classes must be executed in the
> same fork jvm. Another alternative is to use isolated CL in plugin and
> discover them there.
That would be more efficient. We may have to take some care and use separate
launchers for discovery and execution though.
> Why you have to {{selectClasspathRoots}} if DiscoverySelectors already exist
> on the classpath? They are not found by SPI?
Indeed they are not load via SPI. The JUnit platform uses a builder pattern to
create a discovery request. There is a nicely comprehensive example here:
[https://junit.org/junit5/docs/5.0.0/api/org/junit/platform/launcher/core/LauncherDiscoveryRequestBuilder.html]
The discovery request is executed by all available TestEngine implementations.
The test engine implementations are loaded via SPI.
> 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)
