language-testing-strategy

What problem does it solve?

It prevents teams from shipping false-confidence tests by defining a language- and runtime-specific test strategy that targets the actual failure modes (concurrency, boundaries, native memory, contracts, and CI evidence) rather than generic “test theater.”

Core Features & Use Cases

• Runtime failure-mode coverage: Maps risks like races, async cancellation bugs, GC/FFI issues, sanitizer-detectable native defects, and contract drift to the right test types for the chosen language/runtime.
• CI evidence requirements: Ensures CI runs the checks that correspond to the stated risk (e.g., race detector, sanitizer lanes, fuzzing, mutation testing, and concurrency stress where applicable).
• Safety against flaky and mock drift: Requires hermetic fixtures, discourages mock-only validation, and mandates a flake quarantine + root-cause protocol instead of retry masking.
• Boundary and hostile-input testing: Forces dynamic-language boundary validation and hostile-input tests for security-relevant surfaces, including fuzz/property testing and CWE-mapped boundary cases.

Quick Start

Ask for a language-testing strategy by telling the agent which language/runtime you are changing, what failure modes you expect, and which acceptance criteria must be proven by CI evidence.