@ParameterizedTest and @MethodSource in JUnit 5
Fast recall
Quick revision
Core answer
Whether you write DRY tests and use JUnit 5's parameterisation features effectively
Writing 10 near-identical test methods for 10 input variants — leads to copy-paste bugs and hard-to-maintain tests; @ParameterizedTest is the right tool
Mention @CsvSource for inline small datasets, @EnumSource for enum-driven tests, and custom @ArgumentsSource providers for more complex test data generation
Interview-ready guide
Interview answer
@ParameterizedTest runs the same test with different inputs — replacing 10 copy-pasted methods with one. JUnit 5 reports each input as a separate test case, so you still see exactly which combination failed.
Three sources cover most cases. @ValueSource for single primitives — testing validation against blank strings, negative numbers. @CsvSource for input-output pairs — price and discount percentage mapped to expected result. @MethodSource for complex objects — returning Stream with custom types.
The real value isn't less code — it's revealing edge cases. When all inputs and expected outputs are listed together, gaps become obvious. Adding a new test case is one line instead of copying a method.
@MethodSource methods must be static and return Stream. Use descriptive names — they appear in test reports, and a failed parameterized test must immediately show which combination failed.
@ParameterizedTest and @MethodSource in JUnit 5
Direct Answer
@ParameterizedTest replaces multiple near-identical test methods with a single test driven by a stream of arguments. @MethodSource points to a static factory method returning a Stream<Arguments>. Each Arguments entry maps to the test method's parameters. This is ideal for testing boundary conditions, validation rules, or business logic with many input/output combinations without duplicating test code.
Deep Dive & Architecture
TDD is a development practice where you write a failing test before writing the production code.
The cycle is: Red — write the smallest possible failing test.
Green — write the minimum production code to make it pass. Refactor — clean up the code while keeping all tests green. Benefits include built-in test coverage, emergent design, and a safety net for future changes. The key discipline is writing the minimal code to pass each test, then improving it in the refactor phase.
Saying you write mostly integration tests — this shows misunderstanding of cost vs confidence ratio
Common Mistakes & Pitfalls
Writing 10 near-identical test methods for 10 input variants — leads to copy-paste bugs and hard-to-maintain tests; @ParameterizedTest is the right tool
Check your understanding
Answer these without looking back at the article.
- What is Test-Driven Development (TDD) and how does the red-green-refactor cycle work in practice?
- Test-Driven Development (TDD) — Red-Green-Refactor in Java
- JUnit 5 Assertions and AssertJ — Fluent Test Assertions
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.