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
{
"context": "TTL-window coverage for a dedup store with an injected clock. Predicted baseline failure: the agent advances the clock well past the TTL, asserts the notification is sent again, and stops - never probing the edge, so an implementation using a strictly-greater comparison where greater-or-equal is intended passes unnoticed. The unbounded-growth concern that motivated the TTL is typically not tested at all, because 'the key expired' and 'the entry was released' look like the same statement until you check size(). The skill's value is treating the retention window as a bounded interval with both an expiry rule and a storage consequence.",
"type": "weighted_checklist",
"checklist": [
{
"name": "Test file created",
"description": "A file src/notificationDedup.test.js exists and contains at least one test.",
"max_score": 4
},
{
"name": "Suppression window probed at its edge",
"description": "There is an assertion one millisecond before the TTL showing the duplicate is still suppressed AND an assertion at exactly the TTL showing it is sent again. Testing only a comfortably-past value scores zero on this criterion; testing one side of the edge only caps it at half.",
"max_score": 26
},
{
"name": "Expired entries are released, not just reported absent",
"description": "A test asserts the store's size() falls once entries expire - through sweep() or through the lazy delete on get(). A suite that only asserts a re-send happens after expiry scores zero here: that behaviour is identical whether or not the memory is ever reclaimed, and reclaiming it is why the TTL exists.",
"max_score": 24
},
{
"name": "Time advanced through the injected clock",
"description": "MUST NOT wait in real time. The test moves time by controlling the now function the store was constructed with. Any real sleep, real-delay promise, or raised timeout used to cross the window scores zero on this criterion.",
"max_score": 16
},
{
"name": "Sweep return value asserted",
"description": "A test calls sweep() and asserts how many entries it removed, distinguishing a sweep that found stale entries from one that found none.",
"max_score": 10
},
{
"name": "Live entries survive a sweep",
"description": "A test holds both a stale and a fresh key, sweeps, and asserts the fresh key still suppresses while the stale one does not. A sweep that removed everything would otherwise pass the criteria above.",
"max_score": 10
},
{
"name": "Key scoping covered",
"description": "A test shows the dedup key distinguishes users or notification kinds, so suppression of one does not suppress another.",
"max_score": 6
},
{
"name": "Fresh store, transport and clock per test",
"description": "MUST NOT share a store, transport, or mutable clock variable across tests at module scope; a clock left advanced by one test would silently expire another test's keys.",
"max_score": 4
}
]
}