Using JUnit 5 Parameterized Tests to Reduce Duplication
Learn how to replace repetitive @Test methods with a single @ParameterizedTest that runs for each input set, plus tips on sources, converters, and pitfalls.
Loading…
ReadMeFeed / Community knowledge
#junit5
Real questions. Useful conversations. Find the people who know your stack.
junit
javaChoosing the Right JUnit 5 Parameterized Test Source Annotation
A decision guide that compares @ValueSource, @EnumSource, @MethodSource, and @CsvSource, shows when each fits, and provides a Maven‑based example you can run to validate the choice.
Using JUnit 5's @RepeatedTest to Catch Flaky Tests
Learn how JUnit 5's @RepeatedTest runs a test method multiple times, why it helps expose flaky behavior, and what trade‑offs to watch for.
Configuring deterministic execution order for multiple @ExtendWith annotations in JUnit 5
Goal: Ensure predictable execution order of multiple JUnit 5 extensions When a test class is annotated with several @ExtendWith entries, each registering extensions that implement lifecycle callbacks such as BeforeEachCallback or AfterEachCallback, the JUnit Platform does not guarantee a deterministic invocation order unless the extensions also implement Ord
karate.callSingle Caching in Parallel Runs: Shared State and the JUnit 4 to JUnit 5 Boundary
Karate's callSingle feature is intended to execute a feature once and cache its result for the duration of a test run, so parallel scenarios can share setup data such as tokens or seed records. The cache is scoped to the Karate runtime or JVM, not to an individual feature file. The JUnit 4 to JUnit 5 runner transition in Karate 1.x is a compatibility boundar
karatelabsCucumber JVM parallel execution: hook thread-affinity guarantee for scenario-scoped @Before/@After
Thread-affinity uncertainty for scenario hooks When running Cucumber JVM scenarios in parallel via JUnit 5's parallel execution or Cucumber's --threads option, reliable management of thread-local resources such as WebDriver instances or database connections depends on whether @Before and @After hooks execute on the same thread as their associated scenario. T
RepeatedTest with @TestInstance(PER_CLASS) yields varying instance IDs
Determine whether JUnit 5’s @RepeatedTest annotation creates a new test instance for each repetition when the test class is annotated with @TestInstance(Lifecycle.PER_CLASS) . The current specification does not explicitly state if the same instance should be reused across repetitions, and the behavior is still under discussion in the project’s issue tracker.
Nondeterministic test execution order in JUnit 5
In JUnit 5, the default execution order of test methods within a class is unspecified. While this design is intended to prevent developers from creating hidden dependencies between test cases, it frequently leads to nondeterministic results across different environments or build runs. The @TestMethodOrder annotation allows for explicit ordering using strateg
TimeoutExtension outcome classification: failure vs error for timed-out tests
JUnit 5's TimeoutExtension currently reports a test that exceeds its @Timeout limit as a failure by throwing org.opentest4j.TestTimedOutException . The extension uses a watchdog thread that interrupts the test thread; if the test code does not respond to interruption, the extension still marks the test as failed rather than treating it as an error or a disti