You built a Banking Portal login test. It works for one user. Now the manager says: "Test it with valid credentials, invalid password, locked account, expired password, empty fields, special characters, SQL injection, and 12 more combinations." Are you going to copy-paste that test method 20 times? That is exactly the problem data-driven testing solves.
Think of it like a restaurant kitchen. The kitchen (test logic) stays the same. The orders (test data) change. You do not build a new kitchen for every customer. You build one kitchen and feed it different orders. Data-driven testing is the same — one test method, many data sets.
// WITHOUT data-driven testing — copy-paste nightmare
public class LoginTests extends BaseTest {
@Test
public void testValidLogin() {
navigateTo("/banking");
LoginPage loginPage = new LoginPage(driver);
loginPage.loginAs("testuser", "password123");
Assert.assertTrue(new DashboardPage(driver).isLoaded());
}
@Test
public void testInvalidPassword() {
navigateTo("/banking");
LoginPage loginPage = new LoginPage(driver);
loginPage.loginAs("testuser", "wrongpass");
Assert.assertTrue(loginPage.isErrorDisplayed());
}
@Test
public void testEmptyUsername() {
navigateTo("/banking");
LoginPage loginPage = new LoginPage(driver);
loginPage.loginAs("", "password123");
Assert.assertTrue(loginPage.isErrorDisplayed());
}
@Test
public void testEmptyPassword() {
navigateTo("/banking");
LoginPage loginPage = new LoginPage(driver);
loginPage.loginAs("testuser", "");
Assert.assertTrue(loginPage.isErrorDisplayed());
}
@Test
public void testBothEmpty() {
navigateTo("/banking");
LoginPage loginPage = new LoginPage(driver);
loginPage.loginAs("", "");
Assert.assertTrue(loginPage.isErrorDisplayed());
}
// ... 15 more nearly identical methods.
// If login flow changes, update ALL 20 methods. Good luck.
}// WITH data-driven testing — ONE method handles everything
@Test(dataProvider = "loginData")
public void testLogin(String username, String password,
String expectedResult) {
navigateTo("/banking");
LoginPage loginPage = new LoginPage(driver);
loginPage.loginAs(username, password);
if ("success".equals(expectedResult)) {
Assert.assertTrue(new DashboardPage(driver).isLoaded(),
"Dashboard should load for: " + username);
} else {
Assert.assertTrue(loginPage.isErrorDisplayed(),
"Error should show for: " + username);
}
}
// 20 combinations? Just add 20 rows of data. Zero copy-paste.| Without Data-Driven | With Data-Driven |
|---|---|
| 20 test methods for 20 data combinations | 1 test method + 20 rows of data |
| Change login flow = update all 20 methods | Change login flow = update 1 method |
| Adding a new test case = copy-paste + modify | Adding a new test case = add 1 row of data |
| Only developers can add test cases | Anyone can add test cases (edit CSV/Excel) |
| 500+ lines of repetitive code | 50 lines of clean code + data file |
Q: What is data-driven testing and why do you use it?
A: Data-driven testing separates test data from test logic. Instead of writing a separate test method for each input combination, I write one test method and feed it multiple data sets from external sources like CSV, Excel, or JSON. This reduces code duplication, makes maintenance easier, and lets non-technical team members add test cases by editing data files. In our framework, we use TestNG DataProvider to inject data into test methods.
Do not confuse data-driven testing with parameterization. Parameterization (via testng.xml) passes a single value like browser name or environment URL. Data-driven testing feeds multiple complete data sets to the same test method. Interviewers specifically ask this difference.
Key Point: Data-driven testing = one test method + many data sets. The kitchen stays the same, only the orders change.