Support MethodSource as custom test source in dynamic tests

[magictractor]

Background

#1467 and #1178 added support for dynamic containers and tests specifying a custom test source via DynamicNode.getTestSourceUri().

These URIs can be used to link dynamic tests and containers with a FileSource, DirectorySource or ClasspathResourceSource.

These sources may optionally have an associated line and column number, which is indicated by using a query string in the URI, such as line=23&column=12.

Proposal

If a URI has a classpath scheme and a method=myMethodName query string then TestFactoryTestDescriptor.fromUri(URI uri) should create and return a MethodSource.

Use cases

I initially encountered this when using @TestFactory to run a test suite without switching engines. That's working (bar linking back to methods in test cases from the test tree in Eclipse), but it is not a compelling use case since suites are being addressed by #744.

However, I can envisage other cases where this would be useful, such as verifying consistent use of Hibernate annotations across Java beans. Previously I've written cumbersome custom PMD rules for this. Dynamic tests could link back to getters in the application source rather than unit tests.

Related issues

• Support classpath resource for custom test source in dynamic tests #1467
• DynamicTest should be able to provide tags and source information to TestDescriptor #1178

Deliverables

• ❌ Add support for creating a MethodSource for a dynamic test if the custom test source URI uses the classpath scheme and a method=myMethodName query string.
• Introduce support for converting from a URI of the form method:<FQMN> to a MethodSource, where FQMN is the fully qualified method name. See the Javadoc for DiscoverySelectors.selectMethod(String) for the supported formats for a FQMN.
• Modify JavaDoc to explain supported URI schemas and query strings.
• Document in User Guide. will be addressed in Document URI TestSource support of dynamic tests in User Guide #1903
• Document in Release Notes.

[marcphilipp]

Thanks for raising the issue. I think that would make sense.

@junit-team/junit-lambda WDYT?

[marcphilipp]

Tentatively assigned to 5.5 M2 for team discussion.

[sbrannen]

Team Decision:

Although we do not foresee that many developers would use such a MethodSource to link to non-test methods (as in the originally listed use cases), we can imagine that such a feature could be useful for linking to methods used as a method reference and similar use cases. We have therefore decided to go ahead with this proposal modified as follows.

Introduce support for converting from a URI of the form method:<FQMN> to a MethodSource, where FQMN is the fully qualified method name. See the Javadoc for DiscoverySelectors.selectMethod(String) for the supported formats for a FQMN.

Ideally, the new method: scheme should be internal to JUnit Jupiter and not leaked into the JUnit Platform.

Note that we will not reuse the classpath: scheme since that scheme is solely for "classpath resources" which a method is not.

[sbrannen]

This issue is currently "up for grabs".

[sbrannen]

FYI: the implementation of this feature should internally delegate to org.junit.platform.commons.util.ReflectionUtils.parseFullyQualifiedMethodName(String) for parsing the FQMN.

[gopinath-langote]

@sbrannen If no one is picked up this. I would like to pick this issue & submit PR.
Let me know!