Hi all So far the bundle only provides JUnit 4 APIs that make access to OSGi services simple. Running JUnit Jupiter tests with Sling JUnit Core is already possible for some time (SLING-9795). However, no support for getting OSGi services is available when writing JUnit Jupiter tests.
I have prepared a PR[1] for Sling JUnit Core providing JUnit Jupiter (aka JUnit 5) support for injecting OSGi services, as well as a Bundle or BundleContext objects, see SLING-10497[2]. The change adds optional dependencies to org.junit.jupiter.api.extension and to org.apache.commons.lang3.reflect. They are optional to maintain backwards compatibility and not force JUnit 4 users to install additional bundles. No I am wondering if we should keep adding Jupiter features to JUnit Core or if we should create a separate bundle for this Jupiter extension. Ultimately, I believe the ideal design would be (have been?) a slim JUnit 4 engine bundle and another bundle with JUnit 4 extensions/utilities and then the same again for Jupiter. The "engine" bundles would only be needed at runtime, while the "extensions/utilities" would represent the API used in test cases. However, we currently have a Sling JUnit Core bundle that contains the JUnit 4 engine (it even embedds and exports JUnit 4), JUnit 4 extensions/utilities and the Jupiter engine (actually it's a JUnit Platform engine that can even run JUnit 4 tests via the VintageTestEngine, but I digress). So adding Jupiter extensions doesn't seem so bad. WDYT? Any thoughts? Is anyone using server-side tests at all? If I don't hear back before Friday, I will merge the PR and start a Sling JUnit Core release. So please give me a quick shout if you're opposed. Regards Julian [1] https://github.com/apache/sling-org-apache-sling-junit-core/pull/8 [2] https://issues.apache.org/jira/browse/SLING-10497
