@ParameterizedTest annotation in JUnit

Introduction

The @ParameterizedTest annotation lets you run the same test many times with different inputs. This helps check if your code works well for many cases without writing many tests.

You want to test a function with many different values quickly.

You want to avoid repeating similar test code for different inputs.

You want to check edge cases and normal cases in one test method.

You want clear test reports showing which input passed or failed.

You want to improve test coverage with less effort.

Syntax

JUnit

@ParameterizedTest
@ValueSource(ints = {1, 2, 3})
void testMethodName(int parameter) {
    // test code using parameter
}

Use @ParameterizedTest above a test method to mark it as parameterized.

Use sources like @ValueSource to provide input values.

Examples

This test runs 3 times, each time with a different fruit name.

JUnit

@ParameterizedTest
@ValueSource(strings = {"apple", "banana", "cherry"})
void testWithStrings(String fruit) {
    assertNotNull(fruit);
}

This test checks that each number is positive.

JUnit

@ParameterizedTest
@ValueSource(ints = {10, 20, 30})
void testWithInts(int number) {
    assertTrue(number > 0);
}

This test uses two parameters per run, checking fruit name length.

JUnit

@ParameterizedTest
@CsvSource({"apple, 5", "banana, 6", "cherry, 6"})
void testWithCsv(String fruit, int length) {
    assertEquals(length, fruit.length());
}

Sample Program

This test runs 3 times, once for each fruit name. It checks that the fruit string is not null.

JUnit

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.ValueSource;
import static org.junit.jupiter.api.Assertions.*;

public class FruitTest {

    @ParameterizedTest
    @ValueSource(strings = {"apple", "banana", "cherry"})
    void testFruitIsNotNull(String fruit) {
        assertNotNull(fruit);
    }
}

Important Notes

Use descriptive test method names to understand what is tested.

Combine @ParameterizedTest with different sources like @ValueSource, @CsvSource, or @MethodSource for flexibility.

Each test run is reported separately, making it easy to see which input failed.

Summary

@ParameterizedTest runs the same test multiple times with different inputs.

It helps test many cases without repeating code.

Use input sources like @ValueSource or @CsvSource to provide test data.

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