Why @ParameterizedTest annotation in JUnit? - Purpose & Use Cases

The Big Idea

What if you could test dozens of cases with just one simple test method?

The Scenario

Imagine you have a calculator app and want to test its addition function with many pairs of numbers. You write a separate test for each pair manually.

The Problem

Writing many similar tests one by one is slow and boring. It's easy to make mistakes or forget some cases. Running all tests takes longer and the code becomes messy.

The Solution

The @ParameterizedTest annotation lets you run the same test logic with different inputs automatically. You write the test once and provide many data sets. This saves time and keeps tests clean.

Before vs After

✗ Before

void testAdd1() { assertEquals(3, add(1, 2)); }
void testAdd2() { assertEquals(5, add(2, 3)); }

✓ After

@ParameterizedTest
@CsvSource({"1, 2, 3", "2, 3, 5"})
void testAdd(int a, int b, int expected) { assertEquals(expected, add(a, b)); }

What It Enables

You can easily test many input cases with less code, making your tests faster, clearer, and less error-prone.

Real Life Example

Testing a login form with many username and password combinations to ensure all valid and invalid inputs behave correctly.

Key Takeaways

Manual repetitive tests are slow and error-prone.

@ParameterizedTest runs one test with many inputs automatically.

This makes testing faster, cleaner, and more reliable.

Practice

1. What is the main purpose of the @ParameterizedTest annotation in JUnit?

easy

A. To group multiple test classes together

B. To skip a test method during execution

C. To mark a test method as the only one to run

D. To run the same test multiple times with different inputs

Solution

1. Step 1: Understand the role of @ParameterizedTest

   The annotation allows running one test method repeatedly with different input values.

2. Step 2: Compare with other options

   Skipping tests or grouping classes are done by other annotations, not @ParameterizedTest.

3. Final Answer:

   To run the same test multiple times with different inputs -> Option D

4. Quick Check:

   @ParameterizedTest = run test with many inputs [OK]

Hint: Think: same test, many inputs, no code repetition [OK]

Common Mistakes:

• Confusing @ParameterizedTest with @Test
• Thinking it skips tests
• Assuming it groups test classes

2. Which of the following is the correct way to provide integer values to a @ParameterizedTest using @ValueSource?

easy

A. @ValueSource(ints = {1, 2, 3})

B. @ValueSource(values = {1, 2, 3})

C. @ValueSource(strings = {1, 2, 3})

D. @ValueSource(numbers = {1, 2, 3})

Solution

1. Step 1: Recall @ValueSource syntax

   For integers, the correct attribute is 'ints', so @ValueSource(ints = {...}) is correct.

2. Step 2: Check other options

   'values', 'strings', and 'numbers' are invalid attributes for @ValueSource with integers.

3. Final Answer:

   @ValueSource(ints = {1, 2, 3}) -> Option A

4. Quick Check:

   Use 'ints' for integer arrays in @ValueSource [OK]

Hint: Use 'ints' attribute for integer arrays in @ValueSource [OK]

Common Mistakes:

• Using 'values' instead of 'ints'
• Using 'strings' for numbers
• Using unsupported attribute names

3. Given the following test method, what will be the output when running the parameterized test?

@ParameterizedTest
@ValueSource(strings = {"apple", "banana"})
void testLength(String fruit) {
    System.out.println(fruit.length());
}

medium

A. 5 and 6 printed on separate lines

B. 6 and 5 printed on separate lines

C. Only 5 printed once

D. Compilation error due to missing annotation

Solution

1. Step 1: Identify input values

   The test runs twice with inputs "apple" and "banana".

2. Step 2: Calculate string lengths

   "apple" length is 5, "banana" length is 6, so output prints 5 then 6 on separate lines.

3. Final Answer:

   5 and 6 printed on separate lines -> Option A

4. Quick Check:

   String lengths = 5, 6 [OK]

Hint: Check each input's length printed separately [OK]

Common Mistakes:

• Mixing order of outputs
• Expecting only one print
• Assuming compilation error

4. Identify the error in the following parameterized test code:

@ParameterizedTest
@ValueSource(ints = {1, 2, 3})
void testIsPositive(String number) {
    assertTrue(Integer.parseInt(number) > 0);
}

medium

A. Missing @Test annotation

B. Method parameter type should be int, not String

C. ValueSource should use strings instead of ints

D. assertTrue cannot be used in parameterized tests

Solution

1. Step 1: Check parameter type vs ValueSource

   @ValueSource provides ints, but method parameter is String, causing type mismatch.

2. Step 2: Correct parameter type

   Change method parameter to int to match input type and avoid parsing.

3. Final Answer:

   Method parameter type should be int, not String -> Option B

4. Quick Check:

   Parameter type must match @ValueSource type [OK]

Hint: Match method parameter type with @ValueSource data type [OK]

Common Mistakes:

• Using wrong parameter type
• Forgetting @ParameterizedTest annotation
• Misusing assertTrue in parameterized tests

5. You want to test a method that checks if a number is even using @ParameterizedTest with multiple inputs including 0, -2, and 3. Which of the following test method signatures and annotations correctly achieve this?

hard

A. @ParameterizedTest
@ValueSource(ints = {0, -2, 3})
void testIsEven(int number) {
assertEquals(number % 2, 0);
}

B. @ParameterizedTest
@ValueSource(ints = {0, -2, 3})
void testIsEven(int number) {
assertEquals(0, number % 2);
}

C. @ParameterizedTest
@CsvSource({"0, true", "-2, true", "3, false"})
void testIsEven(int number, boolean expected) {
assertEquals(expected, number % 2 == 0);
}

D. @ParameterizedTest
@CsvSource({"0, true", "-2, true", "3, false"})
void testIsEven(String number, boolean expected) {
assertEquals(expected, Integer.parseInt(number) % 2 == 0);
}

Solution

1. Step 1: Understand input and expected output

   We want to test numbers with expected boolean results, so two parameters are needed.

2. Step 2: Check annotation and method signature

   @CsvSource allows multiple parameters; method parameters match types (int, boolean) and assertion compares expected with actual.

3. Step 3: Analyze other options

   Options A and B have incorrect assertEquals argument order or logic; D uses String parameter unnecessarily.

4. Final Answer:

   Option C correctly uses @CsvSource with matching parameters and assertion -> Option C

5. Quick Check:

   Use @CsvSource for multiple inputs and expected results [OK]

Hint: Use @CsvSource for inputs plus expected results [OK]

Common Mistakes:

• Using wrong assertEquals argument order
• Mismatching parameter types
• Using @ValueSource when multiple parameters needed