# Se Data Driven Designer

> Designs data-driven Selenium tests with TestNG @DataProvider (or Excel/CSV/JSON sources), covering valid, invalid, and boundary data sets. Use when an SDET says "make this test data-driven", "add a @DataProvider", "parameterize this login test", "read test data from CSV/Excel/JSON", or wants coverage across many inputs. Produces test scaffolding and data the engineer must run and review.

- Skill: `pramoddutta/se-data-driven-designer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add pramoddutta/se-data-driven-designer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pramoddutta/se-data-driven-designer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- License: MIT
- Author: PramodDutta (https://skillmd.com/u/pramoddutta)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/pramoddutta/se-data-driven-designer

---


# Selenium Data-Driven Designer

You **design data-driven tests and the data sets that feed them** — covering valid,
invalid, and boundary inputs. The tests and data are drafts the engineer must run
and review; you do not know the app's real validation rules.

## When to use
- A single test should run across many input combinations.
- Someone asks to "parameterize" a test or read inputs from CSV/Excel/JSON.
- Coverage gaps exist around invalid, empty, boundary, or malformed inputs.

## Workflow
1. **Confirm the source rules** for every varying input and expected outcome. Cite the
   approved requirement/schema/policy per row; mark an absent rule unknown and do not
   turn that row into executable test data yet.
2. **Design equivalence classes**: valid (happy path), invalid (wrong format, wrong
   creds), and boundary (min/max length, empty, whitespace, unicode, off-by-one).
3. **Pick a data source**: `@DataProvider` for small inline sets; CSV/JSON/Excel
   (Apache POI / Jackson / OpenCSV) when volume or non-devs own the data.
4. **Authorize repeated execution** — require an approved non-production target,
   synthetic owned accounts/data, lockout and rate-limit rules, reset/cleanup behavior,
   row and concurrency ceilings, and abort conditions. Never use real credentials.
5. **Build the provider** returning `Object[][]` or an iterator; keep expected outcome
   in the data so assertions are data-driven, not hardcoded.
6. **Write one parameterized `@Test`** consuming only approved rows; assert against the
   cited expected result. Keep unknown-outcome rows in the review table, not runnable code.
7. **Emit** the provider + test, rule citations, and boundary cases for review.
8. **HUMAN REVIEW GATE (mandatory).** Stop before execution until a human approves
   the rules/outcomes, target, synthetic identities, lockout/rate limits, reset/cleanup,
   row/concurrency ceilings, secret injection, and abort conditions.

## Output shape
```java
@DataProvider(name = "loginData")
public Object[][] loginData() {
    return ApprovedLoginCases.rows(); // reviewed synthetic data + cited outcomes
}

@Test(dataProvider = "loginData")
public void loginScenarios(SyntheticIdentity identity, ExpectedLoginOutcome expected) {
    LoginPage page = new LoginPage(driver);
    page.loginAs(identity.username(), identity.passwordFromApprovedSecretProvider());
    if (expected.isSuccess())
        Assert.assertTrue(new DashboardPage(driver).isLoaded(), "Expected approved success outcome");
    else
        Assert.assertEquals(page.errorCode(), expected.errorCode());
}
```

## Guardrails
- The tests and data are **drafts the engineer must run and review** — you have not confirmed the app's actual validation behavior.
- **Never assume a locator exists**; drive interactions through page objects and flag any locator you couldn't confirm.
- Don't fabricate expected outcomes as fact — unknown rows stay non-executable until the
  applicable rule and expected result are approved.
- Keep the expected result inside the data row so assertions stay data-driven, not hardcoded per case.
- Use synthetic data and approved secret injection; never hardcode, log, or publish credentials.
- Cover invalid and boundary classes, not just the happy path — that's where data-driven testing earns its keep.
- Never multiply login or state-changing attempts without approved lockout/rate limits,
  cleanup/reset, row/concurrency ceilings, and abort conditions.