Test data and fixture generation
Generating edge cases for payloads, tokens, encodings, date formats, regex matches, and parser failures.
Takeaway
Use AI to propose edge cases, then anchor the final fixtures in deterministic utilities and assertions.
01
Ask for categories, not just values
Prompt for empty inputs, malformed inputs, Unicode, boundary lengths, timezone offsets, repeated keys, invalid encodings, and realistic user mistakes. Categories help coverage survive beyond one generated example.
The assistant is useful for breadth. The developer is responsible for choosing which cases become stable tests and which are just exploratory ideas.
- Ask for valid, invalid, boundary, and malicious-looking examples separately.
- Include parser-specific failures such as malformed JSON, YAML indentation, and invalid Base64.
- Include realistic copy-paste errors from terminals, spreadsheets, logs, and docs.
02
Make fixtures deterministic
Generated UUIDs, timestamps, passwords, hashes, and regex samples should be captured in test files once selected. Tests should not depend on a fresh AI answer to remain valid.
Random generation is useful for discovery, but checked-in tests need stable values. If randomness remains part of the unit under test, assert shape and bounds rather than exact output.
- Freeze selected examples in source control.
- Use deterministic hashes and date conversions for exact assertions.
- Assert generated UUID and password shape instead of exact values.
03
Tie cases to behavior
Every fixture should prove an expected status, output, error message, or boundary condition. A large fixture list without assertions is noise.
The best fixture names explain why the value exists. Future reviewers should be able to tell which regression the case protects.
- Name fixtures after the behavior they protect.
- Keep one assertion close to each important edge case.
- Delete generated cases that do not influence test coverage.