C++ Testing (Agent Skill)
Agent-focused testing workflow for modern C++ (C++17/20) using GoogleTest/GoogleMock with CMake/CTest.
When to Use
- Writing new C++ tests or fixing existing tests
- Designing unit/integration test coverage for C++ components
- Adding test coverage, CI gating, or regression protection
- Configuring CMake/CTest workflows for consistent execution
- Investigating test failures or flaky behavior
- Enabling sanitizers for memory/race diagnostics
When NOT to Use
- Implementing new product features without test changes
- Large-scale refactors unrelated to test coverage or failures
- Performance tuning without test regressions to validate
- Non-C++ projects or non-test tasks
Core Concepts
- TDD loop: red → green → refactor (tests first, minimal fix, then cleanups).
- Isolation: prefer dependency injection and fakes over global state.
- Test layout:
tests/unit, tests/integration, tests/testdata.
- Mocks vs fakes: mock for interactions, fake for stateful behavior.
- CTest discovery: use
gtest_discover_tests() for stable test discovery.
- CI signal: run subset first, then full suite with
--output-on-failure.
TDD Workflow
Follow the RED → GREEN → REFACTOR loop:
- RED: write a failing test that captures the new behavior
- GREEN: implement the smallest change to pass
- REFACTOR: clean up while tests stay green
Code Examples
Basic Unit Test (gtest)
Fixture (gtest)
Mock (gmock)
CMake/CTest Quickstart
Running Tests
Debugging Failures
- Re-run the single failing test with gtest filter.
- Add scoped logging around the failing assertion.
- Re-run with sanitizers enabled.
- Expand to full suite once the root cause is fixed.
Coverage
Prefer target-level settings instead of global flags.
GCC + gcov + lcov:
Clang + llvm-cov:
Sanitizers
Flaky Tests Guardrails
- Never use
sleep for synchronization; use condition variables or latches.
- Make temp directories unique per test and always clean them.
- Avoid real time, network, or filesystem dependencies in unit tests.
- Use deterministic seeds for randomized inputs.
Best Practices
DO
- Keep tests deterministic and isolated
- Prefer dependency injection over globals
- Use
ASSERT_* for preconditions, EXPECT_* for multiple checks
- Separate unit vs integration tests in CTest labels or directories
- Run sanitizers in CI for memory and race detection
DON'T
- Don't depend on real time or network in unit tests
- Don't use sleeps as synchronization when a condition variable can be used
- Don't over-mock simple value objects
- Don't use brittle string matching for non-critical logs
Common Pitfalls
- Using fixed temp paths → Generate unique temp directories per test and clean them.
- Relying on wall clock time → Inject a clock or use fake time sources.
- Flaky concurrency tests → Use condition variables/latches and bounded waits.
- Hidden global state → Reset global state in fixtures or remove globals.
- Over-mocking → Prefer fakes for stateful behavior and only mock interactions.
- Missing sanitizer runs → Add ASan/UBSan/TSan builds in CI.
- Coverage on debug-only builds → Ensure coverage targets use consistent flags.
Optional Appendix: Fuzzing / Property Testing
Only use if the project already supports LLVM/libFuzzer or a property-testing library.
- libFuzzer: best for pure functions with minimal I/O.
- RapidCheck: property-based tests to validate invariants.
Minimal libFuzzer harness (pseudocode: replace ParseConfig):
Alternatives to GoogleTest
- Catch2: header-only, expressive matchers
- doctest: lightweight, minimal compile overhead