language-testing-strategy

Define runtime-accurate test strategies for software changes across languages and execution environments.

4|Updated May 16, 2026
One-click install
npx skills add https://github.com/machenjie/rd-skills --skill language-testing-strategy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: language-testing-strategy
Source: https://github.com/machenjie/rd-skills/tree/main/src/foundation/capabilities/language-testing-strategy
Command: npx skills add https://github.com/machenjie/rd-skills --skill language-testing-strategy

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

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.

Frequently Asked Questions about language-testing-strategy

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design a test strategy that catches concurrency and race conditions?

A runtime-accurate test strategy targets concurrency and race conditions by mapping them to specific test types like race detection, concurrency stress tests, and sanitizer lanes. This ensures CI evidence proves real runtime safety rather than generic test coverage.

What is the best way to prevent false-confidence tests from mock drift?

To prevent false-confidence tests from mock drift, your test strategy should require hermetic fixtures, discourage mock-only validation, and mandate a flake quarantine with root-cause analysis instead of retry masking.

How do I validate hostile-input boundaries for security-relevant surfaces?

Validate hostile-input boundaries by defining a test strategy that forces dynamic-language boundary validation, CWE-mapped boundary cases, and fuzz or property testing specifically for security-relevant surfaces.

Does mutation testing help prove runtime safety for native memory defects?

Mutation testing helps prove runtime safety by setting mutation score targets that ensure tests actually detect defects, while sanitizer-detectable native memory issues are validated through dedicated sanitizer CI lanes.

How do I detect contract drift in my integration tests?

Detect contract drift by applying contract testing within your test strategy, ensuring that integration tests enforce hermetic fixtures and validate interactions against expected runtime behavior rather than relying solely on mocks.

When should I include fuzzing and sanitizer lanes in my CI pipeline?

Include fuzzing and sanitizer lanes in CI when your risk profile expects native memory defects, boundary issues, or runtime failure modes, ensuring the pipeline generates evidence that proves actual safety against those specific threats.