Why data separation improves test coverage in Selenium Java - Automation Benefits in Action

Verify login functionality with multiple user credentials

Preconditions (1)

Step 1: Enter username '[e-mail]' in the username field

Step 2: Enter password 'Password1!' in the password field

Step 3: Click the login button

Step 4: Verify that the user is redirected to the dashboard page

Step 5: Log out and return to the login page

Step 6: Repeat the above steps with username '[e-mail]' and password 'Password2!'

Step 7: Repeat the above steps with username '[e-mail]' and password 'Password3!'

✅ Expected Result: Each user is able to log in successfully and is redirected to the dashboard page after login

Automation Requirements - Selenium WebDriver with TestNG

Assertions Needed:

Verify current URL contains '/dashboard' after login

Verify login button is clickable before clicking

Verify logout button is present after login

Best Practices:

Use Page Object Model to separate page interactions

Use explicit waits to wait for elements to be clickable or visible

Separate test data from test logic using data providers

Use assertions to validate expected outcomes clearly

Automated Solution

Selenium Java

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.testng.Assert;
import org.testng.annotations.AfterClass;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;
import java.time.Duration;

public class LoginTest {
    private WebDriver driver;
    private WebDriverWait wait;

    @BeforeClass
    public void setUp() {
        // Set path to chromedriver executable if needed
        driver = new ChromeDriver();
        wait = new WebDriverWait(driver, Duration.ofSeconds(10));
        driver.manage().window().maximize();
    }

    @DataProvider(name = "loginData")
    public Object[][] loginData() {
        return new Object[][] {
            {"[e-mail]", "Password1!"},
            {"[e-mail]", "Password2!"},
            {"[e-mail]", "Password3!"}
        };
    }

    @Test(dataProvider = "loginData")
    public void testLogin(String username, String password) {
        driver.get("https://example.com/login");

        WebElement usernameField = wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("username")));
        WebElement passwordField = driver.findElement(By.id("password"));
        WebElement loginButton = driver.findElement(By.id("loginBtn"));

        usernameField.clear();
        usernameField.sendKeys(username);
        passwordField.clear();
        passwordField.sendKeys(password);

        wait.until(ExpectedConditions.elementToBeClickable(loginButton));
        loginButton.click();

        // Verify URL contains '/dashboard'
        wait.until(ExpectedConditions.urlContains("/dashboard"));
        Assert.assertTrue(driver.getCurrentUrl().contains("/dashboard"), "User is not on dashboard page after login");

        // Verify logout button is present
        WebElement logoutButton = wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("logoutBtn")));
        Assert.assertTrue(logoutButton.isDisplayed(), "Logout button is not displayed after login");

        // Logout to prepare for next test
        logoutButton.click();

        // Wait until back on login page
        wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("loginBtn")));
    }

    @AfterClass
    public void tearDown() {
        if (driver != null) {
            driver.quit();
        }
    }
}

This test uses Selenium WebDriver with TestNG to automate login tests for multiple users.

Setup: We open a Chrome browser and set an explicit wait to handle dynamic elements.

Data separation: The @DataProvider method loginData holds different username and password pairs. This separates test data from test logic, making it easy to add or change users without modifying the test code.

Test method: The testLogin method runs once for each data set. It navigates to the login page, enters credentials, clicks login, and verifies the user lands on the dashboard page by checking the URL and presence of the logout button.

Assertions: We assert the URL contains '/dashboard' and the logout button is visible to confirm successful login.

Best practices: We use explicit waits to avoid timing issues, clear input fields before typing, and use Page Object Model principles by separating data and actions logically (though a full Page Object class is not shown here for simplicity).

Cleanup: After each login, the test logs out to reset the state for the next user. Finally, the browser closes after all tests.

Common Mistakes - 4 Pitfalls

Hardcoding test data inside the test method

Using Thread.sleep() instead of explicit waits

Not verifying page state after login

Not resetting state between test runs

Bonus Challenge

Now add data-driven testing with 3 different inputs using TestNG DataProvider

Show Hint

Practice

1. Why does separating test data from test scripts improve test coverage in Selenium Java?

easy

A. It makes the test scripts run faster by reducing code size.

B. It allows running the same test logic with many different data sets easily.

C. It removes the need for assertions in tests.

D. It automatically fixes bugs in the application under test.

Solution

1. Step 1: Understand the role of data separation

   Separating data from test scripts means test logic stays the same while data changes independently.

2. Step 2: Connect data separation to test coverage

   This allows running tests with many data variations, covering more scenarios without rewriting code.

3. Final Answer:

   It allows running the same test logic with many different data sets easily. -> Option B

4. Quick Check:

   Data separation = more data variations = better coverage [OK]

Hint: More data sets with same test = better coverage [OK]

Common Mistakes:

• Thinking data separation speeds up test execution
• Believing it removes need for assertions
• Assuming it fixes application bugs automatically

2. Which of the following is the correct way to separate test data in Selenium Java using TestNG?

easy

A. Store test data only in comments within the test code.

B. Hardcode all test data inside the test method.

C. Write test data inside the main() method.

D. Use @DataProvider annotation to supply data to test methods.

Solution

1. Step 1: Identify proper data separation technique in Selenium Java

   TestNG's @DataProvider allows supplying multiple data sets to a test method externally.

2. Step 2: Evaluate options for correctness

   Hardcoding data or putting it in comments or main() method does not separate data properly.

3. Final Answer:

   Use @DataProvider annotation to supply data to test methods. -> Option D

4. Quick Check:

   @DataProvider = data separation in TestNG [OK]

Hint: Use @DataProvider to separate data in TestNG tests [OK]

Common Mistakes:

• Hardcoding data inside test methods
• Confusing main() method with test data storage
• Storing data in comments which is ignored by code

3. Given the following TestNG test with @DataProvider, what will be the total number of test executions?

@Test(dataProvider = "loginData")
public void testLogin(String user, String pass) {
  // test steps
}

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

medium

A. 3

B. 2

C. 1

D. 0

Solution

1. Step 1: Count data sets in @DataProvider

   The data provider returns 3 arrays, each with user and pass values.

2. Step 2: Understand test executions per data set

   TestNG runs the test method once per data set, so 3 executions total.

3. Final Answer:

   3 -> Option A

4. Quick Check:

   3 data sets = 3 test runs [OK]

Hint: Count data rows in @DataProvider for test runs [OK]

Common Mistakes:

• Counting only one test run ignoring data sets
• Confusing number of parameters with number of runs
• Assuming zero runs without understanding data provider

4. You have a test that uses a CSV file for data input but the test fails because it reads only the first line repeatedly. What is the likely cause?

medium

A. The code does not iterate through all CSV rows properly.

B. The browser driver is not initialized.

C. The test script has no assertions.

D. The CSV file is empty.

Solution

1. Step 1: Analyze the symptom

   The test reads only the first line repeatedly, so data iteration is faulty.

2. Step 2: Identify cause related to data separation

   Not iterating through all rows means data separation is incomplete or code logic is wrong.

3. Final Answer:

   The code does not iterate through all CSV rows properly. -> Option A

4. Quick Check:

   Repeated first line = missing data iteration [OK]

Hint: Check data iteration loops when data repeats [OK]

Common Mistakes:

• Assuming empty file without checking content
• Blaming missing assertions for data reading issues
• Confusing driver initialization with data reading

5. How does separating test data from test logic help teams improve test maintenance and coverage in Selenium Java projects?

hard

A. It forces tests to run only once per project to save time.

B. Developers write all test data inside test methods to keep control.

C. Testers can update data files without changing test code, enabling more scenarios quickly.

D. It removes the need for test reports and logs.

Solution

1. Step 1: Understand team roles in test automation

   Separating data lets testers manage data independently, without needing code changes.

2. Step 2: Connect separation to maintenance and coverage

   This allows quick updates and adding many data scenarios, improving coverage and reducing maintenance effort.

3. Final Answer:

   Testers can update data files without changing test code, enabling more scenarios quickly. -> Option C

4. Quick Check:

   Data separation = easier updates + more scenarios [OK]

Hint: Separate data so testers update without coding [OK]

Common Mistakes:

• Thinking developers must write all data inside tests
• Believing tests run only once to save time
• Assuming data separation removes need for reports