[
https://issues.apache.org/jira/browse/SUREFIRE-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981190#comment-16981190
]
Tibor Digana edited comment on SUREFIRE-1724 at 11/24/19 9:34 PM:
------------------------------------------------------------------
[~mpkorstanje]
The interface {{org.junit.platform.engine.DiscoverySelector}} v1.3.2 is
implemented by 10 default implementations.
It would be worth to write a trivial GitHub project with your proposal
{code:java}
DiscoverySelectors.selectClasspathRoots(Set.of(
Paths.get("file:/path/to1.jar"),
Paths.get("file:/path/to2.jar"),
Paths.get("file:/path/to3.jar")
));
{code}
and see the {{UniqueId}}-s and we will maybe see the leafs in the tree. I am
especially interested in {{ClasspathResourceSelector}} for the Cucumber. Then
the configuration would be logical accoring to these findings. The approach in
Surefire will be obvious then and the integration tests will be easily written
accordingly because the expectations (in JVM forks) will be feasible. This
analysis is important for the SUREFIRE-1535 too (applicable for the TestNG but
maybe for JUnit5 too). I saw the implementation of the discovery mechanism and
i saw that it worked with loaded classes which means that the static context of
class may be loaded in discovery phase. I guess this might be a problem for
some users but we are not there yet with our analysis.
was (Author: tibor17):
The interface {{org.junit.platform.engineDiscoverySelector.}} v1.3.2 is
implemented by 10 default implementations.
It would be worth to write a trivial GitHub project with your proposal
{code:java}
DiscoverySelectors.selectClasspathRoots(Set.of(
Paths.get("file:/path/to1.jar"),
Paths.get("file:/path/to2.jar"),
Paths.get("file:/path/to3.jar")
));
{code}
and see the {{UniqueId}}-s and we will maybe see the leafs in the tree. I am
especially interested in {{ClasspathResourceSelector}} for the Cucumber. Then
the configuration would be logical accoring to these findings. The approach in
Surefire will be obvious then and the integration tests will be easily written
accordingly because the expectations (in JVM forks) will be feasible. This
analysis is important for the SUREFIRE-1535 too (applicable for the TestNG but
maybe for JUnit5 too). I saw the implementation of the discovery mechanism and
i saw that it worked with loaded classes which means that the static context of
class may be loaded in discovery phase. I guess this might be a problem for
some users but we are not there yet with our analysis.
> 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)
