[
https://issues.apache.org/jira/browse/SUREFIRE-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981279#comment-16981279
]
Tibor Digana edited comment on SUREFIRE-1724 at 11/25/19 4:03 AM:
------------------------------------------------------------------
[~mpkorstanje]
The configuration would not be so simple like you said because we should think
in advance and do two steps ahead and never one step back. This means that our
plan is also SUREFIRE-726 and there i see that we can wrap the selectors in one
more XML element {{testListProcessor}}. This is really a processor of tests
because we are loading the tests from Jars and dirs. As for instance the issue
SUREFIRE-726 talks about a Map between List of paths to the List of test
classes, and run-order processing but it is too simple I would say. More
generic solution with files and dirs and mapping them to some kind of generic
object is the way to go. And this fits to all other future changes with the
communication protocol using JSON. As for instance the resulting object can be
anything for whatever provider (depends on what representation is understood by
the concrete provider), e.g.:
* UniqueId: [class]: some.Test (junit5 format)
* class: some.Test
* class-method: pkg.MyTest#myMethod
* suite-xml-file: /path/to/TestNg-suite.xml
* suite-xml-files: TestNg-suite1.xml,TestNg-suite2.xml
Here in this implementation of the processor it is the JUnit5 library which
discovers the tests. In some other implementations it may be Jandex to lookup
tests upon their annotations without loading the classes in any isolated
classloader. It has also internal benefits for the old JUnit3/4 and TestNg
providers. Maybe some more like the Spock. Every impl may alter the behavior
for particular providet GA(V).
was (Author: tibor17):
[~mpkorstanje]
The configuration would not be so simple like you said because we should think
in advance and do two steps ahead and never one step back. This means that our
plan is also SUREFIRE-726 and there i see that we can wrap the selectors in one
more XML element {{testListProcessor}}. This is really a processor of tests
because we are loading the tests from Jars and dirs. As for instance the issue
SUREFIRE-726 talks about a Map between List of paths to the List of test
classes but it is too simple I would say. More generic solution with files and
dirs and mapping them to some kind of generic object is the way to go. And this
fits to all other future changes with the communication protocol using JSON. As
for instance the resulting object can be anything for whatever provider
(depends on what representation is understood by the concrete provider), e.g.:
* UniqueId: [class]: some.Test (junit5 format)
* class: some.Test
* class-method: pkg.MyTest#myMethod
* suite-xml-file: /path/to/TestNg-suite.xml
* suite-xml-files: TestNg-suite1.xml,TestNg-suite2.xml
Here in this implementation of the processor it is the JUnit5 library which
discovers the tests. In some other implementations it may be Jandex to lookup
tests upon their annotations without loading the classes in any isolated
classloader. It has also internal benefits for the old JUnit3/4 and TestNg
providers. Maybe some more like the Spock. Every impl may alter the behavior
for particular providet GA(V).
> 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)
