cpp-testing
Skill1 starsChanged 7 months agoMITView on GitHub
Use only when writing/updating/fixing C++ tests, configuring GoogleTest/CTest, diagnosing failing or flaky tests, or adding coverage/sanitizers.
18 other projects use a version of this, 9 of them edited.
Adopted by
Most recently taken up by
- majay123/my-embedded-skillsword for word, first seen Nov 8, 2026
- Premchand006/AI-assistant-skillstheir own version, first seen Nov 1, 2026
- TsinHzl/claude-code-configedited, first seen Nov 1, 2026
- ghvinashvili/specagentedited, first seen Nov 1, 2026
- renepf/claude-skillsedited, first seen Oct 25, 2026
- davidanthonyn/claude-skillsword for word, first seen Oct 20, 2026
Other versions18 projects use a version of this.
Word for word · 8
- loulanyue/awesome-claude-notes★ 272100% same
- majay123/my-embedded-skills★ 8100% same
- junimnjw/everything-claude-code★ 1100% same
- SamuelNDCE/claude-super-skill-library★ 1100% same
- TironFox/everything-claude-code★ 1100% same
- davidanthonyn/claude-skills★ 0100% same
- MohamedEssam0-0/claude-skills★ 0100% same
- PeterYang888/claude-skills★ 0100% same
Edited · 9
- Fmarzochi/EGC★ 61100% same
- gongyijie85/dsh-ecc★ 8100% same
- ghvinashvili/specagent★ 799% same
- ronmkr/PromptBook★ 299% same
- TsinHzl/claude-code-config★ 261% same
- Ronnasayd/aipp★ 1100% same
- royaluniondesign-sys/claude-os★ 1100% same
- MortuisVMain/ai-agent-superpowers★ 0100% same
- renepf/claude-skills★ 0100% same
Wrote their own version · 1
- Premchand006/AI-assistant-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository269 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .codex/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- examples/CLAUDE.mdCLAUDE.md
- .cursor/rules/common-agents.mdCursor rule
- .cursor/rules/common-coding-style.mdCursor rule
- .cursor/rules/common-development-workflow.mdCursor rule
- .cursor/rules/common-git-workflow.mdCursor rule
- .cursor/rules/common-hooks.mdCursor rule
- .cursor/rules/common-patterns.mdCursor rule
- .cursor/rules/common-performance.mdCursor rule
- .cursor/rules/common-security.mdCursor rule
- .cursor/rules/common-testing.mdCursor rule
- .cursor/rules/golang-coding-style.mdCursor rule
- .cursor/rules/golang-hooks.mdCursor rule
- .cursor/rules/golang-patterns.mdCursor rule
- .cursor/rules/golang-security.mdCursor rule
- .cursor/rules/golang-testing.mdCursor rule
- .cursor/rules/kotlin-coding-style.mdCursor rule
- .cursor/rules/kotlin-hooks.mdCursor rule
- .cursor/rules/kotlin-patterns.mdCursor rule
- .cursor/rules/kotlin-security.mdCursor rule
- .cursor/rules/kotlin-testing.mdCursor rule
- .cursor/rules/php-coding-style.mdCursor rule
- .cursor/rules/php-hooks.mdCursor rule
- .cursor/rules/php-patterns.mdCursor rule
- .cursor/rules/php-security.mdCursor rule
- .cursor/rules/php-testing.mdCursor rule
- .cursor/rules/python-coding-style.mdCursor rule
- .cursor/rules/python-hooks.mdCursor rule
- .cursor/rules/python-patterns.mdCursor rule
- .cursor/rules/python-security.mdCursor rule
- .cursor/rules/python-testing.mdCursor rule
- .cursor/rules/swift-coding-style.mdCursor rule
- .cursor/rules/swift-hooks.mdCursor rule
- .cursor/rules/swift-patterns.mdCursor rule
- .cursor/rules/swift-security.mdCursor rule
- .cursor/rules/swift-testing.mdCursor rule
- .cursor/rules/typescript-coding-style.mdCursor rule
- .cursor/rules/typescript-hooks.mdCursor rule
- .cursor/rules/typescript-patterns.mdCursor rule
- .cursor/rules/typescript-security.mdCursor rule
- .cursor/rules/typescript-testing.mdCursor rule
- agent-introspection-debuggingSkill
- agent-sortSkill
- api-designSkill
- article-writingSkill
- backend-patternsSkill
- brand-voiceSkill
- bun-runtimeSkill
- claude-apiSkill
- coding-standardsSkill
- content-engineSkill
- crosspostSkill
- deep-researchSkill
- dmux-workflowsSkill
- documentation-lookupSkill
- e2e-testingSkill
- eval-harnessSkill
- everything-claude-code-conventionsSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
19 rules. 15 are common, 0 are distinctive, and 4 are very specific to this project.
15
Common
Most of the 9 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 30
Isolation: prefer dependency injection and fakes over global state.
- Very specific: line 33
CTest discovery: use gtest_discover_tests() for stable test discovery.
- Very specific: line 34
CI signal: run subset first, then full suite with --output-on-failure.
- Common: line 38
Follow the RED → GREEN → REFACTOR loop:
- Common: line 40
RED: write a failing test that captures the new behavior
- Common: line 202
Add scoped logging around the failing assertion.
- Common: line 208
Prefer target-level settings instead of global flags.
- Very specific: line 268
Never use sleep for synchronization.
- Common: line 270
Avoid real time, network, or filesystem dependencies in unit tests.
- Common: line 271
Use deterministic seeds for randomized inputs.
- Common: line 277
Keep tests deterministic and isolated
- Common: line 278
Prefer dependency injection over globals
- Very specific: line 279
Use ASSERT_* for preconditions, EXPECT_* for multiple checks
- Common: line 281
Run sanitizers in CI for memory and race detection
- Common: line 285
Don't depend on real time or network in unit tests
- Common: line 286
Don't use sleeps as synchronization when a condition variable can be used
- Common: line 287
Don't over-mock simple value objects
- Common: line 288
Don't use brittle string matching for non-critical logs
- Common: line 302
Only use if the project already supports LLVM/libFuzzer or a property-testing library.
“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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
// tests/add_test.cpp
#include <gtest/gtest.h>
int Add(int a, int b); // Provided by production code.
TEST(AddTest, AddsTwoNumbers) { // RED
EXPECT_EQ(Add(2, 3), 5);
}
// src/add.cpp
int Add(int a, int b) { // GREEN
return a + b;
}
// REFACTOR: simplify/rename once tests passCode Examples
Basic Unit Test (gtest)
// tests/calculator_test.cpp
#include <gtest/gtest.h>
int Add(int a, int b); // Provided by production code.
TEST(CalculatorTest, AddsTwoNumbers) {
EXPECT_EQ(Add(2, 3), 5);
}Fixture (gtest)
// tests/user_store_test.cpp
// Pseudocode stub: replace UserStore/User with project types.
#include <gtest/gtest.h>
#include <memory>
#include <optional>
#include <string>
struct User { std::string name; };
class UserStore {
public:
explicit UserStore(std::string /*path*/) {}
void Seed(std::initializer_list<User> /*users*/) {}
std::optional<User> Find(const std::string &/*name*/) { return User{"alice"}; }
};
class UserStoreTest : public ::testing::Test {
protected:
void SetUp() override {
store = std::make_unique<UserStore>(":memory:");
store->Seed({{"alice"}, {"bob"}});
}
std::unique_ptr<UserStore> store;
};
TEST_F(UserStoreTest, FindsExistingUser) {
auto user = store->Find("alice");
ASSERT_TRUE(user.has_value());
EXPECT_EQ(user->name, "alice");
}Mock (gmock)
// tests/notifier_test.cpp
#include <gmock/gmock.h>
#include <gtest/gtest.h>
#include <string>
class Notifier {
public:
virtual ~Notifier() = default;
virtual void Send(const std::string &message) = 0;
};
class MockNotifier : public Notifier {
public:
MOCK_METHOD(void, Send, (const std::string &message), (override));
};
class Service {
public:
explicit Service(Notifier ¬ifier) : notifier_(notifier) {}
void Publish(const std::string &message) { notifier_.Send(message); }
private:
Notifier ¬ifier_;
};
TEST(ServiceTest, SendsNotifications) {
MockNotifier notifier;
Service service(notifier);
EXPECT_CALL(notifier, Send("hello")).Times(1);
service.Publish("hello");
}CMake/CTest Quickstart
# CMakeLists.txt (excerpt)
cmake_minimum_required(VERSION 3.20)
project(example LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
include(FetchContent)
# Prefer project-locked versions. If using a tag, use a pinned version per project policy.
set(GTEST_VERSION v1.17.0) # Adjust to project policy.
FetchContent_Declare(
googletest
# Google Test framework (official repository)
URL https://github.com/google/googletest/archive/refs/tags/${GTEST_VERSION}.zip
)
FetchContent_MakeAvailable(googletest)
add_executable(example_tests
tests/calculator_test.cpp
src/calculator.cpp
)
target_link_libraries(example_tests GTest::gtest GTest::gmock GTest::gtest_main)
enable_testing()
include(GoogleTest)
gtest_discover_tests(example_tests)cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
cmake --build build -j
ctest --test-dir build --output-on-failureRunning Tests
ctest --test-dir build --output-on-failure
ctest --test-dir build -R ClampTest
ctest --test-dir build -R "UserStoreTest.*" --output-on-failure./build/example_tests --gtest_filter=ClampTest.*
./build/example_tests --gtest_filter=UserStoreTest.FindsExistingUserDebugging 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.
option(ENABLE_COVERAGE "Enable coverage flags" OFF)
if(ENABLE_COVERAGE)
if(CMAKE_CXX_COMPILER_ID MATCHES "GNU")
target_compile_options(example_tests PRIVATE --coverage)
target_link_options(example_tests PRIVATE --coverage)
elseif(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
target_compile_options(example_tests PRIVATE -fprofile-instr-generate -fcoverage-mapping)
target_link_options(example_tests PRIVATE -fprofile-instr-generate)
endif()
endif()GCC + gcov + lcov:
cmake -S . -B build-cov -DENABLE_COVERAGE=ON
cmake --build build-cov -j
ctest --test-dir build-cov
lcov --capture --directory build-cov --output-file coverage.info
lcov --remove coverage.info '/usr/*' --output-file coverage.info
genhtml coverage.info --output-directory coverageClang + llvm-cov:
cmake -S . -B build-llvm -DENABLE_COVERAGE=ON -DCMAKE_CXX_COMPILER=clang++
cmake --build build-llvm -j
LLVM_PROFILE_FILE="build-llvm/default.profraw" ctest --test-dir build-llvm
llvm-profdata merge -sparse build-llvm/default.profraw -o build-llvm/default.profdata
llvm-cov report build-llvm/example_tests -instr-profile=build-llvm/default.profdataSanitizers
option(ENABLE_ASAN "Enable AddressSanitizer" OFF)
option(ENABLE_UBSAN "Enable UndefinedBehaviorSanitizer" OFF)
option(ENABLE_TSAN "Enable ThreadSanitizer" OFF)
if(ENABLE_ASAN)
add_compile_options(-fsanitize=address -fno-omit-frame-pointer)
add_link_options(-fsanitize=address)
endif()
if(ENABLE_UBSAN)
add_compile_options(-fsanitize=undefined -fno-omit-frame-pointer)
add_link_options(-fsanitize=undefined)
endif()
if(ENABLE_TSAN)
add_compile_options(-fsanitize=thread)
add_link_options(-fsanitize=thread)
endif()Flaky Tests Guardrails
- Never use
sleepfor 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):
#include <cstddef>
#include <cstdint>
#include <string>
extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
std::string input(reinterpret_cast<const char *>(data), size);
// ParseConfig(input); // project function
return 0;
}Alternatives to GoogleTest
- Catch2: header-only, expressive matchers
- doctest: lightweight, minimal compile overhead
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

