Build-an-X for idempotency tests in any async/job/API context - idempotency-key handling (per Stripe / AWS prescriptive guidance pattern), retry-safe semantics (exactly-once vs at-least-once vs at-most-once), side-effect commutativity verification, fingerprint-based dedup, idempotency-window tuning. Use when authoring tests for any system where the same input could be processed twice (SQS Standard at-least-once, RabbitMQ requeue, retry-on-error logic, webhook redelivery, browser double-click, mobile-network retry).
87
86%
Does it follow best practices?
Impact
95%
1.01xAverage score across 3 eval scenarios
Passed
No findings from the security scan
Test file created
100%
100%
Suppression window probed at its edge
100%
100%
Expired entries are released, not just reported absent
100%
100%
Time advanced through the injected clock
100%
100%
Sweep return value asserted
100%
100%
Live entries survive a sweep
100%
0%
Key scoping covered
0%
33%
Fresh store, transport and clock per test
100%
100%
Test file created
100%
100%
Calls genuinely overlap
100%
100%
Side effect asserted exactly once under the race
100%
100%
Every racing caller receives the same outcome
100%
100%
Race widened beyond two callers
100%
100%
No sleep used to sequence the race
100%
100%
Fresh store and gateway per test
100%
100%
Test file created
100%
100%
Side effect asserted exactly once on replay
100%
100%
Replay returns the original response
100%
100%
Key reuse with a different payload is covered
100%
100%
No credit applied on the mismatch path
100%
100%
Distinct keys still apply separately
0%
100%
Missing key covered
100%
100%
Fresh store and ledger per test
100%
100%