2026-08-30 · Test Data Generation
One thing first, because the term is crowded: if you are here for masking, subsetting, or environment provisioning, that is classic TDM and not this product. And this is not fake data either. Faker and Mockaroo manufacture plausible inputs. Every row of ours carries the computed answer.
Open any data-driven-testing tutorial for Playwright, Postman, or REST-assured. The example is always the same table: input columns, then a column called Expected_Result. The tutorial shows you how to loop over the rows. It never says where the expected results come from, because everyone knows where they come from: a person worked them out, once, in a spreadsheet, and the suite has trusted that spreadsheet ever since.
The testing literature has a name for this: the oracle problem. Tools became excellent at generating inputs. What the system should answer for each input stayed your problem.
Survey the market and it sorts into four rungs, each stopping short of the answer:
So the precise claim is not "no tool computes expected results." It is the composite: partitions learned from execution, the answer computed per row, and the requirement link attached, in one framework-agnostic artifact, with no second model to maintain. That composite is what we could not find shipped anywhere.
Boundary value analysis and equivalence partitioning are decades old. What made them expensive was declaring the partitions by hand and keeping the declarations honest as the rules changed. A test designer decides ages 17 and 18 sit on a boundary and writes it down. Next quarter the underwriting table moves the boundary to 21, and the declaration is quietly wrong. No tool will tell you.
Karate learns the partitions by observing your executable business rules run. Equivalence classes and boundaries are discovered, not declared, including the ones buried in lookup tables that no static reading of a spec would surface. When the rules change, the next run learns the new boundaries. There is no flowchart to hand-build and no state model to keep in sync: the rules are executable, so the rules are the model.
{ "driver_age": 17, "vehicle_class": "sport",
"expected_result": { "eligible": false, "reason": "age below minimum for class" },
"requirements": ["REQ-114"] }
Four things travel on every generated row: the inputs, chosen deliberately (boundary values, equivalence-class representatives, pairwise and covering-array combinations, pruned for feasibility); the expected result the rulebook computed; a plain-English audit of how the answer was reached, so a disagreement can be adjudicated instead of argued; and the ids of the requirements the row exercises.
This is the part we suspect matters most to people who will never adopt our framework, and we mean that sincerely. The deck is plain JSON or CSV in the canonical data-driven-testing shape. A Playwright fixture loops over it. The Postman collection runner consumes the CSV. A REST-assured data provider reads the JSON. Zero Karate anywhere in the loop: Karate generates the deck, your framework runs it.
Decks are served as JSON from the API and MCP surface today, and one-command CSV and JSON file export is shipping this quarter. If your stack is Playwright and it is staying Playwright, the deck is still yours to take.
Run the same deck inside Karate and each passing row becomes execution evidence against the requirement it names: the traceability matrix updates, coverage is graded, and a requirement whose rows fail shows up in the release verdict with the failing input attached. The deck is the on-ramp. The traceability is what it opens onto.
The full picture, including pairwise strength selected by business criticality and the consumption examples per framework, is on the test data generation page.
Most test-data tools stop at the input.
Every row in our deck includes the computed answer, and the requirement it proves.
See the deck