JUnit 5 Jupiter @Test visibility across module boundaries

In multi-module Java projects, test method visibility across module dependency boundaries determines whether non-public @Test methods are silently dropped or inadvertently exposed to consumers of compiled artifacts.

JUnit 4 default runners require test methods to be public; non-public @Test methods are silently ignored unless a customized runner or rule configures discovery.

JUnit 5 Jupiter supports @Test on non-public methods through TestClass visibility checks, but default execution still expects public methods, creating a migration friction point where test suites may silently drop tests or leak internals into generated reports, IDE autocomplete, and compiled JARs.

The precise threshold at which module encapsulation interacts with JUnit's visibility checks remains ambiguous across version transitions.

What mechanisms does JUnit 5 Platform provide to filter @Test methods by visibility across module boundaries?

Can LauncherDiscoveryRequest filters reliably exclude non-public methods while preserving full suite execution?

How does JUnit 4's silent ignore behavior differ from JUnit 5's visibility check in terms of reported test counts and artifact exposure?