[
https://issues.apache.org/jira/browse/SUREFIRE-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981035#comment-16981035
]
M.P. Korstanje commented on SUREFIRE-1724:
------------------------------------------
I think I'm closer to #2 but I would say neither.
Terms:
* Discovery request: A request to discover test cases. A discovery requests is
composed of multiple selectors. When executed it yields a collection of test
identifiers.
* Discovery selector: A specific location to look for tests. These take many
forms most of which are provider specific. For example for Junit5 we can
discover tests in a classpath root, package, class, file folder or uniqueId.
Surefire currently implements an implicit discovery selector that I would
describe as _classes discovered by surefire_.
* Test Identifier: Some string that a provider can use to execute a specific
test.
I would imagine the following process:
*1. Surefire issues a discovery request to a provider.*
By default the discovery request will only contain _classes discovered by
surefire_. However if provider specific selectors are configured these selector
will be added to the request.
A challenge here would be to find a nice way to disable the default discovery
request by surefire when it is unwanted.
*2. The provider resolves this discovery request and replies with list of test
identifiers.*
Providers that do not have the ability to discover tests will fall back to
Surefires build in _exclusively_ classes discovery functionality. Otherwise
they'll use their own. For Junit4 for example this would mean returning the
list of _classes discovered by surefire_.
Providers that can discover tests will do so. If requested to discovery classes
exclusively Junit5 would be issued with a discovery selector for the classes
discovered by surefire. If any other selectors were provided they would be
added to the discovery request. The discovered tests would be provided to
surefire by their uniqueId.
*3. If no tests are discovered by any provider surefire exits with the usual
warning.*
This changes from the current situation where surefire exits when surefire
wasn't able to find tests.
*4. Surefire distributes the test identifiers between forks.*
This doesn't change much from the existing ForkedBooter/Runner setup. We
distribute the test identifiers rather then classes between the different forks.
*5. The forked provider executes the requested tests.*
The provider converts the test identifier back into something it can execute.
Either a class name for JUnit4 or a UniqueId for Junit 5.
> 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)
