Test data and configuration

Test data is the input a test uses, such as user names, products and expected messages. Configuration is everything that changes between runs, such as the base URL (the address of the app under test), the browser and timeouts. A framework is only as reliable as these two. Interviewers ask how you drive tests with external data, how you switch environments and where passwords live, because clear answers show you have run a suite for real, not only written tests.

Data-driven tests with a DataProvider

"Data-driven" means the steps stay the same and only the data changes. In TestNG, a @DataProvider method returns rows, and each row becomes one run of the test:

The rows can come from anywhere Java can read. Here they come from a CSV file:

@DataProvider(name = "logins")
public Object[][] logins() throws IOException {
    List<String> lines = Files.readAllLines(Paths.get("src/test/resources/data/logins.csv"));
    return lines.stream()
            .skip(1)                                   // header row
            .map(line -> line.split(",", -1))
            .toArray(Object[][]::new);
}

@Test(dataProvider = "logins")
public void login(String user, String password, String expectedMessage) { ... }

A DataProvider may return Object[][] or Iterator<Object[]>; the iterator builds rows one at a time, which helps with large files. This simple split is fine for plain data; fields that contain commas need a CSV library. For JSON, a library such as Jackson (a popular Java library for reading JSON) turns each entry into a small Java class, which keeps tests readable: row.user() instead of row[0].

Excel is still common in service companies. The third-party Apache POI library reads it: open the workbook, take the sheet, loop from row 1 (row 0 is the header), and use DataFormatter so each cell comes back as the text you see, not 12.0 for the number 12. Close the workbook with try-with-resources (a Java form that closes the file for you). In interviews, add that CSV or JSON is simpler unless business people maintain the data in Excel.

Configuration

Keep everything that changes between runs out of the code: base URLs, browser, timeouts, Grid address (Selenium Grid runs browsers on other machines) and feature flags (switches that turn an app feature on or off). An environment is a separate copy of the app, such as qa for testers or staging for last checks before release. A common shape is one properties file (a text file of key=value lines) per environment, such as config/qa.properties and config/staging.properties, plus a small class that loads the right file once and lets system properties override it:

public final class Config {
    private static final Properties PROPS = load();

    private static Properties load() {
        String env = System.getProperty("env", "qa");
        Properties p = new Properties();
        try (InputStream in = Config.class.getResourceAsStream("/config/" + env + ".properties")) {
            if (in == null) throw new IllegalStateException("No config for env " + env);
            p.load(in);
        } catch (IOException e) {
            throw new UncheckedIOException(e);
        }
        return p;
    }

    public static String get(String key) {
        return System.getProperty(key, PROPS.getProperty(key));
    }
}

Now mvn test -Denv=staging -Dbrowser=firefox switches both, because Maven's Surefire plugin passes -D values to the tests as system properties. The second argument of getProperty is the default used when no -D value was given.

Secrets

Passwords, API keys and tokens never go into the repository, not even in a "test" properties file. CI tools (servers that run your tests automatically, such as Jenkins or GitHub Actions) keep them as secrets and pass them to the job as environment variables, which are named values set outside your program. The framework reads System.getenv("TEST_USER_PASSWORD") and stops at start-up with a clear message when the value is missing. Logs and reports should hide them.

Managing test data across runs

• Reference data that rarely changes, such as countries or product types, lives in files in version control (a tool such as Git that stores every change to your files).
• Accounts per environment live next to the environment config, with passwords from CI.
• Data a test changes, such as orders, carts and new users, is created by the test itself, ideally through an API in set-up, with unique values such as a random suffix. It is removed afterwards.

A builder gives sensible defaults, so each test sets only what it cares about: new OrderBuilder().withItems(3).paidBy("card").build().

How to answer in an interview

For "how do you manage test data?", name the three kinds of data and where each lives, give one example of a test creating its own data through an API, and finish with secrets and switching environments in one sentence each. For "how do you read Excel?", describe the DataProvider and Apache POI, then mention that CSV or JSON is often simpler.

Common mistakes

• Committing passwords in a config file.
• Editing a config file in CI instead of passing -D values.
• Tests that rely on data left behind by other tests. They fail when run alone, in another order or in parallel.
• Two parallel DataProvider rows sharing one account that one of them changes.

Recap

A DataProvider turns each data row into one test run. Configuration lives in one file per environment, chosen with -Denv and overridden by -D values. Secrets come from the CI secret store. Each test creates the data it changes and cleans it up, which keeps tests independent.