Add proof-of-concept Java junit test rule #12177
Conversation
patricklaw
force-pushed
the
junit
branch
3 times, most recently
from
49bcbee to
8b0517e
Compare
There was a problem hiding this comment.
Agree with @tdyas : this is a really lovely capstone. Thanks @patricklaw!
| argv=[ | ||
| coursier.coursier.exe, | ||
| "java", | ||
| "--system-jvm", # TODO(#12293): use a fixed JDK version from a subsystem. |
There was a problem hiding this comment.
I assume that this should be fixed to read the option value, and junit_test.py should override the option value?
There was a problem hiding this comment.
Yeah, something to that effect. It's not entirely obvious to me right now how junit test runner JVM selection should interact with javac JDK selection. A straightforward next step would be to just make a subsystem like javac's with the same options for JVM version and system JVM special casing, and just consult that here. Unlike javac, though, junit doesn't need special wrappers around Coursier for finding the literal javac binary on the filesystem; it can just use cs java ... as seen here.
| lockfile = await Get( | ||
| CoursierResolvedLockfile, | ||
| CoursierLockfileForTargetRequest(Targets(transitive_targets.closure)), | ||
| ) |
There was a problem hiding this comment.
cc @Eric-Arellano and @chrisjrn : Worth taking a look here to see how this aligns with your plans (see PR description as well). If we're able to find a semantic model for locked resolves that works across Python and the JVM, that would be a huge win in terms of consistency and teachability.
|
@patricklaw: Any reason to not just land this? |
This implementation is just good enough to demonstrate how to use the existing Pants Java infrastructure to compile and consume Java source for the purpose of executing junit tests. This initial iteration has several limitations: * jUnit5 (org.junit.platform:junit-platform-console:1.7.2) is hard-coded as the JUnit runner in the rule source. As needed, this can be hoisted into a subsystem for configurability. By design, junit4 is not supported as a **runner**, because its classpath scanning isn't powerful enough. However, junit4 tests can still be run with the junit5 runner. * junit_tests targets have the same requirement of java_library targets that there must be exactly 1 coursier_lockfile dependency in the transitive closure of the junit_tests target. In practice this means that any third party dependencies required by the test source must also be shared by the library targets upon which the test transitively depends. Lockfile subsetting will mostly make this a non-issue, but it's still unfortunate that all test targets are indirectly locked to all other test targets that transitively depend on the same Java library code. * Due to pantsbuild#12293, the test runner currently hard-codes the Coursier `--system-jvm` argument. Future revisions will expose this as an option via `junit_test` parameters and/or a junit subsystem. [ci skip-rust] [ci skip-build-wheels]
NOTE TO REVIEWERS: This is currently branched from #12425 as that is required for this to run. For the purpose of this review, it's safe to only review the changes under src/python/pants/backend/java/test, as everything else will disappear after that PR is submitted and main is rebased into this branch.
This implementation is just good enough to demonstrate how to use the existing Pants Java infrastructure to compile and consume Java source for the purpose of executing junit tests. This initial iteration has several limitations:
jUnit5 (org.junit.platform:junit-platform-console:1.7.2) is hard-coded as the JUnit runner in the rule source. As needed, this can be hoisted into a subsystem for configurability. By design, junit4 is not supported as a runner, because its classpath scanning isn't powerful enough. However, junit4 tests can still be run with the junit5 runner.
junit_tests targets have the same requirement of java_library targets that there must be exactly 1 coursier_lockfile dependency in the transitive closure of the junit_tests target. In practice this means that any third party dependencies required by the test source must also be shared by the library targets upon which the test transitively depends. Lockfile subsetting will mostly make this a non-issue, but it's still unfortunate that all test targets are indirectly locked to all other test targets that transitively depend on the same Java library code.
Due to
test_java_binary_versionsfromjavac_binary_test.pyis flaky #12293, the test runner currently hard-codes the Coursier--system-jvmargument. Future revisions will expose this as an option viajunit_testparameters and/or a junit subsystem.[ci skip-rust]
[ci skip-build-wheels]