Fix support for package-private test methods

[marcphilipp]

Prior to this commit, when the test super class wss declared in another
package and declared a package-private test method with the same
signature as the subclass, the method from the subclass was silently
ignored. With the changes in this commit, both test methods are
executed, albeit with the same display name.

Fixes #5098.

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes

[mpkorstanje]

I've pushed 31128d6 to make the build green. But I've got some reservations about the way I've done so. For a lack of a better word, I would expect a symmetry of concerns between the unique id segment of a method and the method selector. Currently that symmetry is broken.

[marcphilipp]

I've pushed 31128d6 to make the build green. But I've got some reservations about the way I've done so. For a lack of a better word, I would expect a symmetry of concerns between the unique id segment of a method and the method selector. Currently that symmetry is broken.

Thanks! I have similar reservations. Therefore, I've pushed two commits that solve the issue by introducing a Jupiter-specific, internal DeclaredMethodSelector.

@mpkorstanje WDYT?

[mpkorstanje]

This looks much neater!

We are still left with an adjacent issue that it is not possible to select all method based tests in a class with a collection of method selectors.

I.e. I would expect that while using the EngineDiscoveryRequestResolver I should be able to produce the same test plan by using either one class selector, or a collection of method selectors. Because the MethodSelector equals implementation lacks fidelity that isn't possible yet.

But I think we can fix that on a separate PR.

[marcphilipp]

I would expect that while using the EngineDiscoveryRequestResolver I should be able to produce the same test plan by using either one class selector, or a collection of method selectors. Because the MethodSelector equals implementation lacks fidelity that isn't possible yet.

I agree but the scenario here is truly an edge case and I think we can postpone tackling the adjacent issue. When we do, we also need to think about NestedMethodSelector.

[mpkorstanje]

I agree but the scenario here is truly an edge case and I think we can postpone tackling the adjacent issue. When we do, we also need to think about NestedMethodSelector.

And MethodSource apparently 😄