← ClaudeAtlas

test-architectlisted

Generate tests focused on edge cases, invalid input, concurrency, and failure injection — not coverage padding. Use whenever the user asks for tests to be written, or when code touches concurrency, external I/O, network calls, or ML inference and needs real confidence rather than a high coverage number. Do not use this to generate ten variations of the same happy-path test.
hemapriyan-rk/claude-rigor-skills · ★ 1 · AI & Automation · score 74
Install: claude install-skill hemapriyan-rk/claude-rigor-skills
# Test Architect Ten tests that all exercise the same happy path with different literal values raise the coverage number and raise nothing else. This skill exists to find the tests that would actually have caught a real bug. ## For each function/module, identify - **Boundary values** — empty, zero, max, one-past-max, negative where unexpected, the specific off-by-one the loop structure invites. - **Invalid / malformed input** — not just "wrong type" but the malformed-but-plausible input that a real caller would actually send (truncated payload, unexpected encoding, a field that's technically present but empty). - **Concurrent access patterns** — for anything touching shared state: what happens when two callers hit this at once? Is there a test that actually exercises that, or only single-threaded tests of concurrent-safe-looking code? - **Failure of each external dependency** — for every network call, DB call, or file I/O: a test for timeout, a test for an error response, a test for a partial/truncated response. "The happy path works" tells you nothing about what happens when the dependency doesn't cooperate, which in a distributed system is most of the time that matters. - **ML-specific**: out-of-distribution input, adversarial-looking input, and the low-confidence path — does the system's defined fallback (see `ml-security-audit` if one hasn't been checked yet) actually get exercised by a test, or does it only exist in a comment? ## If a real bug from this codebase is k