Replies: 1 comment
-
One option would be to recommend users to import |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Over at Jazzer, we maintain a library,
com.code-intelligence:jazzer-junit
, with an@FuzzTest
macro that adds fuzzing functionality within JUnit, based on parameterized tests. It also includes a custom test runner based on the Launcher API that can optionally be used to run fuzz tests.On Maven, this library currently has the following dependencies:
Since we do not (and probably shouldn't?) depend on any of the "engine" packages, we do not control the result of Maven's version resolution for e.g.
org.junit.jupiter:junit-jupiter-engine
. But if users end up with version resolutions that leave them with an outdated version oforg.junit.jupiter:junit-jupiter-engine
, then running@FuzzTest
s can fail with obscure errors.Is there any best practice we can employ to ensure that users receive a consistent collection of the different JUnit artifacts and our own minimum version constraints on the API artifacts are honored?
Beta Was this translation helpful? Give feedback.
All reactions