
Generated data is not yet test data
AI can invent ten customers, twenty orders and a series of edge cases in seconds. That sounds like a shortcut to better testing. Yet without explicit expectations, it mainly creates more input: plausible names, random amounts and combinations that cover no clearly identified risk.
A useful setup does not ask AI to invent something new during every Cypress run. It asks AI to propose candidate data first, validates that data against explicit rules and then lets Cypress create a fixed, repeatable state. AI expands the variation. Cypress protects reproducibility.
This distinction matters as vendors move AI closer to test design. On 17 September 2026, IBM announced an agent that drafts test cases and scripts from requirements. IBM also states that engineers remain responsible for reviewing, refining and approving those assets. That is where Quality Engineering starts: not with generation, but with showing why a scenario matters.
Start with the risk, not the prompt
Imagine an application that applies a discount to orders of 100 euros or more. Asking for ‘twenty orders’ will probably produce tidy JSON, but it says nothing about the boundary we need to examine. A stronger instruction describes the rule and the required categories:
Create candidate test data for an order API.
The discount starts at a total amount of EUR 100.00.
Return valid examples for 99.99, 100.00 and 100.01,
plus one missing amount and one amount with too many decimals.
Use fictional identifiers and no personal data.
For every record, include the expected result and the risk rule covered.Make the output verifiable
The gain is not prettier sample data. Every record now has a reason: below the boundary, exactly on it, above it or invalid. A reviewer can assess the set before Cypress consumes it.
Ask the model to fill an agreed JSON structure. Then automatically verify required fields, amount formats, unique identifiers and allowed values. Treat model output as untrusted input: validate it before storing or executing anything.
{
"caseId": "discount-boundary-10000",
"orderTotalCents": 10000,
"expectedDiscountCents": 1000,
"risk": "discount starts exactly at the boundary"
}Let Cypress create the state
Store the approved set under version control, either as a fixture or as input for a test-data API. Never copy production data into the prompt. Fictional names do not make a dataset safe when other fields can still be traced to real people, cases or transactions.
Cypress recommends preparing required state directly through an API or Node task where possible. This is faster and more stable than creating every customer and order through the user interface. A test can read the validated fixture and ask a test-only endpoint to create its records before checking the application:
describe("discount boundary", () => {
beforeEach(() => {
cy.fixture("discount-boundaries").then(({ cases }) => {
cy.request("POST", "/test-support/orders/seed", { cases });
});
});
it("applies the discount from EUR 100", () => {
cy.visit("/orders/discount-boundary-10000");
cy.findByTestId("discount").should("have.text", "€ 10.00");
});
});Generate before the run
When a safe test-data API is unavailable, cy.task() can invoke an existing seed script in the Node process. Restrict the endpoint or task to test environments, verify authorisation and clean up predictably. The browser test does not need to understand the database; it only asks for a known starting state.
Calling an AI model live from a Cypress test looks flexible, but it makes a regression suite harder to explain. Input may vary between runs, an external service can become slow or unavailable, and a failure may come from the application or from newly generated data.
Variation can still be useful during exploration. In that case, record the prompt, model version, settings, generated dataset and validation results. When a scenario reveals a real risk, promote it to a fixed regression case. Randomness can then support discovery without making the regular suite unpredictable.
Five checks for a useful setup
AI can accelerate repetitive combination work and suggest unexpected variants. Quality improves only when a team makes its expectations explicit. Cypress is more than the executor of generated data: it is the control point that turns an idea into a repeatable experiment.
- Which business rule or risk does every record cover?
- Has the output been validated technically and semantically?
- Are production data and identifiable personal data absent from prompts and datasets?
- Can the same approved dataset run locally and in CI?
- Can a failure be traced to data, setup, expectation or product behaviour?
Sources
- Cypress: API testing — Geraadpleegd 24 september 2026
- Cypress: Best Practices — Geraadpleegd 24 september 2026
- Cypress: cy.task() — Geraadpleegd 24 september 2026
- IBM Engineering AI Hub 1.4 — Leveranciersaankondiging van 17 september 2026