Custom display names for parameters in JUnit - Build an Automation Script
import org.junit.jupiter.api.DisplayName; import org.junit.jupiter.api.DisplayNameGeneration; import org.junit.jupiter.api.DisplayNameGenerator; import org.junit.jupiter.params.ParameterizedTest; import org.junit.jupiter.params.provider.ValueSource; import static org.junit.jupiter.api.Assertions.assertTrue; @DisplayNameGeneration(DisplayNameGenerator.ReplaceUnderscores.class) public class CustomDisplayNameTest { @ParameterizedTest(name = "Run {index}: input={0}") @ValueSource(strings = {"apple", "banana", "cherry"}) @DisplayName("Test with custom display names for parameters") void testWithCustomDisplayNames(String fruit) { // Simple assertion to check input is not empty assertTrue(fruit.length() > 0); } }
This test class uses JUnit 5 parameterized tests to run the testWithCustomDisplayNames method with three different string inputs.
The @ParameterizedTest annotation marks the method as parameterized. The name attribute customizes the display name for each parameterized invocation, showing the index and the input value.
The @ValueSource provides the input strings.
The @DisplayName annotation sets a custom name for the test method itself.
The class-level @DisplayNameGeneration(DisplayNameGenerator.ReplaceUnderscores.class) replaces underscores with spaces in method names, improving readability.
The assertion checks that the input string is not empty, a simple valid test.
When running this test, the test report or console output will show the custom display names like "Run 1: input=apple", "Run 2: input=banana", etc.
Now add data-driven testing with 3 different inputs using @CsvSource and customize display names for each input set
Practice
Solution
Step 1: Understand the role of display names
Custom display names help testers and developers read test reports more clearly by showing descriptive names instead of default method names.Step 2: Identify the benefit in test results
Meaningful names improve readability and debugging, making it easier to know what each test case checks.Final Answer:
To make test results easier to understand by showing meaningful names -> Option BQuick Check:
Custom display names = clearer test reports [OK]
- Thinking display names speed up tests
- Assuming display names fix test failures
- Confusing display names with test data generation
Solution
Step 1: Recall the correct annotation for parameterized test names
JUnit 5 uses @ParameterizedTest with the 'name' attribute to set custom display names for parameters.Step 2: Verify syntax correctness
@ParameterizedTest(name = "Test {index} with value {0}") is the correct syntax; other options are invalid annotations.Final Answer:
@ParameterizedTest(name = "Test {index} with value {0}") -> Option AQuick Check:
@ParameterizedTest(name=...) = correct syntax [OK]
- Using non-existent annotations like @TestDisplay
- Confusing @DisplayName with parameterized name attribute
- Misspelling annotation names
@ParameterizedTest(name = "Run {index}: input={0}")
@ValueSource(strings = {"apple", "banana"})
void testFruits(String fruit) { /* test code */ }Solution
Step 1: Understand the index and parameter mapping
The index starts at 1 for the first parameter, so the second test run has index 2 and parameter "banana".Step 2: Substitute values into the display name pattern
Replacing {index} with 2 and {0} with "banana" gives "Run 2: input=banana".Final Answer:
Run 2: input=banana -> Option CQuick Check:
Index 2 + second value banana = Run 2: input=banana [OK]
- Assuming index starts at 0
- Mixing parameter values between runs
- Confusing index with parameter value
@ParameterizedTest(name = "Test {index} - {0}")
@ValueSource(ints = {1, 2, 3})
void testNumbers(int number) {
assertTrue(number > 0);
}Solution
Step 1: Check if 'name' attribute is valid in @ParameterizedTest
@ParameterizedTest supports the 'name' attribute to customize display names.Step 2: Verify placeholders and parameter types
{0} correctly refers to the first parameter, which can be an int from @ValueSource.Step 3: Confirm method and annotation compatibility
Using int parameter with @ValueSource(ints = {...}) is valid and assertTrue is a valid assertion.Final Answer:
There is no error; the code is correct -> Option AQuick Check:
Valid syntax and usage = no error [OK]
- Thinking {0} can't be used with primitive types
- Believing 'name' attribute is unsupported
- Confusing parameter types with annotation requirements
Solution
Step 1: Understand the 'name' attribute flexibility
The 'name' attribute accepts any string with placeholders {index} and {0} to customize display names.Step 2: Check each option's format
The three provided formats all correctly use {index} and {0} with additional text to form valid display names.Step 3: Confirm all options are valid
Since all formats are syntactically correct and achieve the goal, all are acceptable.Final Answer:
All of the following are correct -> Option DQuick Check:
Any string with {index} and {0} works [OK]
- Thinking only one exact format is allowed
- Misplacing placeholders causing syntax errors
- Forgetting to include both {index} and {0}
Ready to prove it?
Pass the test and this pattern moves unknown
