Why parameterization reduces test duplication in JUnit - Automation Benefits in Action
import static org.junit.jupiter.api.Assertions.assertEquals; import static org.junit.jupiter.api.Assertions.assertFalse; import org.junit.jupiter.params.ParameterizedTest; import org.junit.jupiter.params.provider.CsvSource; import org.openqa.selenium.By; import org.openqa.selenium.WebDriver; import org.openqa.selenium.chrome.ChromeDriver; public class LoginTest { WebDriver driver; @ParameterizedTest @CsvSource({ "user1@example.com, Password1", "user2@example.com, Password2", "user3@example.com, Password3" }) void testLoginWithMultipleUsers(String username, String password) { driver = new ChromeDriver(); try { driver.get("http://example.com/login"); driver.findElement(By.id("email")).sendKeys(username); driver.findElement(By.id("password")).sendKeys(password); driver.findElement(By.id("loginButton")).click(); // Wait for redirection - simple implicit wait or explicit wait can be used Thread.sleep(2000); // For simplicity here, better to use explicit wait in real tests String currentUrl = driver.getCurrentUrl(); assertEquals("http://example.com/dashboard", currentUrl, "User should be redirected to dashboard"); boolean errorDisplayed = driver.findElements(By.id("loginError")).size() > 0; assertFalse(errorDisplayed, "No error message should be displayed after successful login"); } catch (InterruptedException e) { e.printStackTrace(); } finally { driver.quit(); } } }
This test uses JUnit 5's @ParameterizedTest with @CsvSource to run the same login test with different username and password combinations.
Each test iteration opens the login page, enters the provided credentials, clicks login, and verifies the user is redirected to the dashboard URL.
Assertions check the URL and that no error message is shown.
Parameterization reduces duplication by avoiding writing separate test methods for each user credential set.
The try-finally block ensures the browser closes after each test run.
Note: Thread.sleep is used here for simplicity but explicit waits are recommended in real tests.
Now add data-driven testing with 3 different inputs using @MethodSource instead of @CsvSource
Practice
Solution
Step 1: Understand parameterization purpose
Parameterization runs the same test method repeatedly with different input values.Step 2: Compare with duplication
This avoids writing separate test methods for each input, reducing repeated code.Final Answer:
It allows running the same test method multiple times with different inputs. -> Option AQuick Check:
Parameterization = multiple inputs, one test method [OK]
- Thinking parameterization fixes bugs automatically
- Confusing parameterization with random data generation
- Believing it merges test classes
Solution
Step 1: Identify correct annotation for parameterized tests
JUnit 5 uses @ParameterizedTest to mark parameterized test methods.Step 2: Check data source annotation
@ValueSource provides input values; it must be combined with @ParameterizedTest.Final Answer:
@ParameterizedTest with @ValueSource is correct syntax. -> Option BQuick Check:
@ParameterizedTest + @ValueSource = correct syntax [OK]
- Using @Test instead of @ParameterizedTest
- Using non-existent @Parameters or @TestSource annotations
- Mixing annotations incorrectly
@ParameterizedTest
@ValueSource(ints = {2, 4, 6})
void testIsEven(int number) {
assertTrue(number % 2 == 0);
}Solution
Step 1: Analyze input values
The input values are 2, 4, and 6, all even numbers.Step 2: Check assertion logic
The assertion checks if number % 2 == 0, which is true for all inputs.Final Answer:
All tests pass because all numbers are even. -> Option CQuick Check:
All inputs even -> assertion true -> tests pass [OK]
- Assuming some numbers are odd without checking
- Confusing assertion logic
- Thinking syntax error exists when it does not
@ParameterizedTest
@ValueSource(strings = {"test", "JUnit"})
void testLength(int length) {
assertTrue(length > 0);
}Solution
Step 1: Check parameter type against @ValueSource data
@ValueSource provides strings, but method parameter is int, causing a type mismatch.Step 2: Understand correct parameter type
The method parameter should be String to match the input data type.Final Answer:
The parameter type should be String, not int. -> Option DQuick Check:
Parameter type must match @ValueSource data type [OK]
- Using wrong parameter type
- Forgetting parentheses in annotations (not the case here)
- Thinking test methods must return values
- Believing assertTrue is disallowed in parameterized tests
Solution
Step 1: Understand test duplication problem
Multiple test methods for positive, negative, zero numbers cause repeated code.Step 2: Apply parameterization to combine tests
Use one parameterized test method with inputs and expected results to cover all cases.Final Answer:
By combining all checks into one parameterized test method with input and expected result parameters. -> Option AQuick Check:
One method + multiple inputs = less duplication [OK]
- Writing separate test classes instead of parameterizing
- Removing assertions which breaks test automation
- Testing only one fixed input
Ready to prove it?
Pass the test and this pattern moves unknown
