How do I install the Cpp Testing skill?

Run npx skillmds@latest add aeondave/cpp-testing in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Cpp Testing safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Cpp Testing?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Cpp Testing free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Cpp Testing?

AeonDave (@aeondave) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Cpp Testing by aeondave — Agent Skill

Name: Cpp Testing
Author: AeonDave

Cpp Testing

C++ testing workflow for unit and integration tests: GoogleTest/GoogleMock, CMake/CTest integration, diagnosing flaky tests, and running sanitizers and coverage for correctness signal. Use when writing or fixing C++ tests and test infrastructure.

AeonDave 5dd6799 5 files · 8.5 KB Updated Sep 17, 2026

File contents

C++ Testing

High-signal workflow for writing and maintaining reliable C++ tests.

When to activate

Adding new unit tests, regression tests, or integration tests
Fixing failing or flaky C++ tests
Wiring GoogleTest with CMake/CTest
Enabling sanitizers for memory/UB/race diagnostics

Outcome expectations

Fast deterministic unit tests with clear failure messages.
Integration tests separated and labeled by cost/risk.
Flake triage follows reproducible, root-cause-first workflow.
Sanitizers/coverage are integrated as recurring quality signal.

Core rules

Tests must be deterministic: no sleeping for synchronization.
Prefer fakes for state, mocks for interactions.
Use ASSERT_* for preconditions, EXPECT_* for additional checks.
Keep unit tests fast; label integration tests separately.
Keep one source of truth for test configuration in CMake targets.
Avoid production-only test hooks unless they expose a real design seam.
Pair with test-driven-development when implementing persistent code or bug fixes test-first.
Pair with testing-reliability for mock/timing anti-patterns and systematic-debugging when symptoms are far from the defect.

Recommended workflow

Define the behavior and test scope (unit vs integration) first.
Add/adjust tests with clear Arrange-Act-Assert structure.
Run focused test selection (ctest -R / gtest filter).
Run sanitizers for memory/UB/races where applicable.
If flaky/failing, minimize reproducer and fix root cause before broad reruns.

Triage loop for failing tests

Reproduce deterministically on one test binary.
Capture failure class: assertion mismatch, crash, timeout, data race, UB.
Narrow input/state until minimal failing case is obtained.
Fix production code first (or fixture isolation), then harden test.
Re-run focused + full suite + sanitizer build.

Resources

Load on demand:

references/googletest-cmake.md — FetchContent + CTest discovery (gtest_discover_tests)
references/test-design.md — unit vs integration, fixtures, parameterized tests
references/sanitizers-coverage.md — ASan/UBSan/TSan + coverage recipes
references/flakes-debugging.md — anti-flake rules, gdb/lldb, Valgrind, MinGW objdump/nm, MSVC dumpbin/WinDbg, sanitizer env vars

---name: cpp-testingdescription: C++ testing workflow for unit and integration tests: GoogleTest/GoogleMock, CMake/CTest integration, diagnosing flaky tests, and running sanitizers and coverage for correctness signal. Use when writing or fixing C++ tests and test infrastructure.license: MIT---# C++ TestingHigh-signal workflow for writing and maintaining reliable C++ tests.## When to activate- Adding new unit tests, regression tests, or integration tests- Fixing failing or flaky C++ tests- Wiring GoogleTest with CMake/CTest- Enabling sanitizers for memory/UB/race diagnostics---## Outcome expectations- Fast deterministic unit tests with clear failure messages.- Integration tests separated and labeled by cost/risk.- Flake triage follows reproducible, root-cause-first workflow.- Sanitizers/coverage are integrated as recurring quality signal.---## Core rules- Tests must be deterministic: no sleeping for synchronization.- Prefer fakes for state, mocks for interactions.- Use `ASSERT_*` for preconditions, `EXPECT_*` for additional checks.- Keep unit tests fast; label integration tests separately.- Keep one source of truth for test configuration in CMake targets.- Avoid production-only test hooks unless they expose a real design seam.- Pair with `test-driven-development` when implementing persistent code or bug fixes test-first.- Pair with `testing-reliability` for mock/timing anti-patterns and `systematic-debugging` when symptoms are far from the defect.---## Recommended workflow1. Define the behavior and test scope (unit vs integration) first.2. Add/adjust tests with clear Arrange-Act-Assert structure.3. Run focused test selection (`ctest -R` / gtest filter).4. Run sanitizers for memory/UB/races where applicable.5. If flaky/failing, minimize reproducer and fix root cause before broad reruns.---## Triage loop for failing tests1. Reproduce deterministically on one test binary.2. Capture failure class: assertion mismatch, crash, timeout, data race, UB.3. Narrow input/state until minimal failing case is obtained.4. Fix production code first (or fixture isolation), then harden test.5. Re-run focused + full suite + sanitizer build.---## ResourcesLoad on demand:- `references/googletest-cmake.md` — FetchContent + CTest discovery (gtest_discover_tests)- `references/test-design.md` — unit vs integration, fixtures, parameterized tests- `references/sanitizers-coverage.md` — ASan/UBSan/TSan + coverage recipes- `references/flakes-debugging.md` — anti-flake rules, gdb/lldb, Valgrind, MinGW objdump/nm, MSVC dumpbin/WinDbg, sanitizer env vars

Frequently asked questions