How to use the Mock Data Generator.
Synthetic data should satisfy declared relationships and remain clearly fictional. Include boundary cases when the goal is testing rather than demonstration.
Make the workflow fit your task.
Define fields, types and relationships, then generate clearly fictional records satisfying those rules. Include deliberate boundary cases for the testing purpose and distinguish valid fixtures from intentionally invalid inputs.
- What you provide
- Schema and test constraints.
- What you get
- Clearly synthetic records satisfying specified relationships.
See the input and the result.
Illustrative input and output · a teaching example, not a live WebAct run
Example input
Generate two fictional orders with unique order_id, valid customer_id and nonnegative amount. Allowed customer IDs: SYN-C1, SYN-C2. Include a zero amount.
Completed example
[
{"order_id": "SYN-O1", "customer_id": "SYN-C1", "amount": 0},
{"order_id": "SYN-O2", "customer_id": "SYN-C2", "amount": 24.5}
]
Both customer references belong to the supplied list. All records are synthetic.Load this input into the prompt, then copy it to WebAct to try the task. Your result may differ from the illustration.
Decisions and troubleshooting.
Can random-looking records be assumed to satisfy a schema?
Validate them. IDs, references and required values can still be inconsistent even when each record looks plausible.
Why do tests fail for reasons unrelated to the feature under test?
Check fixture relationships and constraints. Accidental invalid data can obscure the behavior the test was meant to examine.
Try it with your own source.
Replace the example with your material in the task prompt. Keep the requirements you need, then copy the task into WebAct.
Customize and copy the task ↑