Data providers for parameterization in Selenium Java - Framework Patterns

Framework Mode - Data providers for parameterization

Folder Structure

src/
└── test/
    └── java/
        └── com/
            └── example/
                ├── tests/
                │   └── LoginTest.java
                ├── pages/
                │   └── LoginPage.java
                ├── data/
                │   └── LoginDataProvider.java
                ├── utils/
                │   └── WebDriverFactory.java
                └── config/
                    └── TestConfig.java

Test Framework Layers

• Driver Layer: Manages WebDriver setup and teardown (e.g., WebDriverFactory.java).
• Page Objects: Encapsulate page elements and actions (e.g., LoginPage.java).
• Data Providers: Supply test data for parameterized tests (e.g., LoginDataProvider.java using TestNG @DataProvider).
• Tests: Test classes that use page objects and data providers (e.g., LoginTest.java).
• Utilities: Helper classes for common functions (e.g., WebDriver management).
• Configuration: Central place for environment and test settings (e.g., TestConfig.java).

Configuration Patterns

• Environment Settings: Use property files or Java classes (e.g., TestConfig.java) to define URLs, timeouts.
• Browser Selection: Pass browser type via system properties or config file to WebDriverFactory.
• Credentials & Sensitive Data: Store securely outside code, load at runtime or use environment variables.
• Data Provider Integration: Data providers can read from CSV, Excel, or hardcoded arrays for parameterization.

Test Reporting and CI/CD Integration

• Use TestNG built-in reports and listeners for detailed test results.
• Integrate with tools like Allure or ExtentReports for rich HTML reports.
• Configure CI/CD pipelines (Jenkins, GitHub Actions) to run tests with different data sets automatically.
• Fail tests clearly when data-driven tests fail, showing which data set caused failure.

Best Practices

1. Keep data providers separate from test logic for clarity and reuse.
2. Use descriptive names for data sets to understand test scenarios easily.
3. Limit data provider size to keep tests fast and focused.
4. Use TestNG @DataProvider(name = "name") and reference it explicitly in tests.
5. Validate data provider inputs to avoid test failures due to bad data.

Self Check

Where in this folder structure would you add a new data provider for testing the registration page?

Key Result

Use TestNG Data Providers in a dedicated data package to supply parameterized test data cleanly and efficiently.

Practice

1. What is the main purpose of using a @DataProvider in Selenium Java tests?

easy

A. To run the same test multiple times with different input data

B. To create a new browser instance for each test

C. To skip tests that are not ready

D. To generate reports automatically after tests

Solution

1. Step 1: Understand the role of @DataProvider

   @DataProvider supplies different sets of data to a test method, enabling multiple runs with varied inputs.

2. Step 2: Identify the main benefit

   This helps find bugs that appear only with certain inputs by running the same test repeatedly with different data.

3. Final Answer:

   To run the same test multiple times with different input data -> Option A

4. Quick Check:

   @DataProvider = multiple test runs with varied data [OK]

Hint: DataProvider runs tests repeatedly with different inputs [OK]

Common Mistakes:

• Thinking @DataProvider creates new browsers
• Confusing @DataProvider with test skipping
• Assuming it generates reports automatically

2. Which of the following is the correct syntax to declare a DataProvider method in Selenium Java?

easy

A. @DataProvider
public void dataProviderMethod() { }

B. @Test(dataProvider = "testData")
public void dataProviderMethod() { }

C. @DataProvider(name = "testData")
public void dataProviderMethod() { }

D. @DataProvider(name = "testData")
public Object[][] dataProviderMethod() { return new Object[][] {{"data1"}, {"data2"}}; }

Solution

1. Step 1: Check the method signature for DataProvider

   A DataProvider method must return Object[][] and be annotated with @DataProvider(name = "...").

2. Step 2: Verify the return type and annotation

   @DataProvider(name = "testData") public Object[][] dataProviderMethod() { return new Object[][] {{"data1"}, {"data2"}}; } correctly returns Object[][] and uses the proper annotation with a name.

3. Final Answer:

   @DataProvider(name = "testData") public Object[][] dataProviderMethod() { return new Object[][] {{"data1"}, {"data2"}}; } -> Option D

4. Quick Check:

   DataProvider method returns Object[][] [OK]

Hint: DataProvider methods return Object[][] with @DataProvider annotation [OK]

Common Mistakes:

• Using void return type for DataProvider
• Missing the name attribute in @DataProvider
• Annotating test method instead of DataProvider method

3. Given the following code snippet, what will be the output when the test runs?

@DataProvider(name = "numbers")
public Object[][] data() {
    return new Object[][] { {1, 2}, {3, 4} };
}

@Test(dataProvider = "numbers")
public void testSum(int a, int b) {
    System.out.println(a + b);
}

medium

A. No output because test is skipped

B. 1 and 2 printed on separate lines

C. 3 and 7 printed on separate lines

D. Compilation error due to wrong DataProvider

Solution

1. Step 1: Understand the DataProvider data

   The DataProvider returns two sets: {1, 2} and {3, 4}.

2. Step 2: Calculate the sum for each test run

   First run: 1 + 2 = 3; second run: 3 + 4 = 7; both printed on separate lines.

3. Final Answer:

   3 and 7 printed on separate lines -> Option C

4. Quick Check:

   Sum of pairs = 3, 7 [OK]

Hint: Sum each data pair printed per test run [OK]

Common Mistakes:

• Assuming only one test run happens
• Confusing data sets with single values
• Expecting compilation errors without syntax issues

4. Identify the error in the following DataProvider usage:

@DataProvider(name = "inputData")
public Object[] data() {
    return new Object[] {"A", "B"};
}

@Test(dataProvider = "inputData")
public void testMethod(String input) {
    System.out.println(input);
}

medium

A. DataProvider method should return Object[][], not Object[]

B. Test method parameter type is incorrect

C. Missing @Test annotation on DataProvider method

D. DataProvider name does not match test method

Solution

1. Step 1: Check DataProvider return type

   DataProvider methods must return Object[][] to supply multiple parameter sets.

2. Step 2: Identify mismatch in return type

   The method returns Object[], which is invalid and causes runtime errors.

3. Final Answer:

   DataProvider method should return Object[][], not Object[] -> Option A

4. Quick Check:

   DataProvider return type = Object[][] [OK]

Hint: DataProvider must return Object[][], not Object[] [OK]

Common Mistakes:

• Returning Object[] instead of Object[][]
• Confusing test method parameter types
• Forgetting to match DataProvider name

5. You want to test a login form with multiple username and password combinations using a DataProvider. Which approach correctly handles this scenario to avoid test failures when a password is empty or null?

@DataProvider(name = "loginData")
public Object[][] loginData() {
    return new Object[][] {
        {"user1", "pass1"},
        {"user2", ""},
        {"user3", null}
    };
}

@Test(dataProvider = "loginData")
public void testLogin(String username, String password) {
    // Test logic here
}

hard

A. Remove entries with empty or null passwords from DataProvider

B. Add validation inside testLogin to skip or handle empty/null passwords

C. Change DataProvider to return only usernames without passwords

D. Use separate test methods for each username-password pair

Solution

1. Step 1: Recognize the need to handle edge cases in test method

   Empty or null passwords can cause test failures if not handled properly.

2. Step 2: Implement validation inside testLogin method

   Adding checks to skip or handle empty/null passwords prevents failures and tests robustness.

3. Final Answer:

   Add validation inside testLogin to skip or handle empty/null passwords -> Option B

4. Quick Check:

   Handle edge cases inside test method [OK]

Hint: Validate inputs inside test to handle empty or null values [OK]

Common Mistakes:

• Removing test data instead of handling it
• Ignoring null or empty values causing failures
• Splitting tests unnecessarily instead of parameterizing