Vibe coding
Build a test dataset that exposes a generated app's weak spots
Use a compact set of invented records with boundary values, missing fields and awkward relationships.
Zocri · 2 min read · Sources checked
Make every sample record earn its place
PostgreSQL documents constraints that reject values violating defined rules, including uniqueness and relationships between records. Use that principle when designing test data: each record should probe a rule or a display condition. Ten carefully chosen service requests can reveal more useful information than hundreds of identical rows, provided you explain what each is intended to check.
Begin with an ordinary request that should complete successfully. Add a very long customer name, a missing optional field, an old request and a request with an unusual but valid value. Use invented details and a clearly marked test environment so the samples cannot be mistaken for customer work.
Probe boundaries deliberately
If quantities must be positive, include zero and the largest quantity the business intends to accept. If an appointment requires a service, try a request referring to a removed service. Ask what the app should show rather than allowing an empty label or broken page to define the behavior.
Include repeated values where repetition matters. Two customers may share a name, while an order identifier should remain distinct. Decide which fields identify a record and which merely describe it. A dataset that uses unique names everywhere can hide a mistaken dependence on display text.
Exercise states and relationships
Create records in every important state: draft, pending review, approved, rejected and archived where those states exist. Include a record with multiple related items and one without any. Inspect both the list and detail view, because each may handle incomplete information differently.
Keep a small expectation sheet beside the data. For each record, explain whether it should be accepted, refused or displayed with a particular warning. If a case is invalid on purpose, the useful result is an understandable refusal, not a successful save followed by a later failure.
Keep the set useful after launch
Preserve the sample set as a repeatable review kit. When a real defect appears, add a sanitized example that reproduces the underlying shape without retaining private customer details. The set should grow because it captures new risks, not merely because more rows look impressive.
Run the kit after changes to forms, filters or record handling. Compare results with the expectations and investigate any differences. A realistic dataset does not replace broader testing, but it gives owners a concrete way to inspect the awkward cases a polished empty preview often misses.