KS
Killer-Skills

cpp-testing — cpp-testing setup guide cpp-testing setup guide, C++ test automation with GoogleTest, how to use cpp-testing for C++ development, cpp-testing vs CTest, installing cpp-testing for AI agents, C++ testing best practices with cpp-testing, what is cpp-testing, cpp-testing tutorial for C++ developers, configuring CMake for cpp-testing

Verified
v1.0.0
GitHub

About this Skill

Ideal for C++ Development Agents requiring advanced testing capabilities with GoogleTest and CMake cpp-testing is a specialized AI agent skill for automating and optimizing C++ testing workflows using GoogleTest, CTest, and CMake.

Features

Configures GoogleTest and GoogleMock for unit and integration testing
Utilizes CMake and CTest for consistent test execution and workflow management
Enables test coverage and sanitizers for memory and race diagnostics
Supports C++17 and C++20 standards for modern C++ development
Facilitates debugging of failing or flaky tests for improved test reliability

# Core Topics

affaan-m affaan-m
[62.0k]
[7678]
Updated: 3/6/2026

Quality Score

Top 5%
92
Excellent
Based on code quality & docs
Installation
SYS Universal Install (Auto-Detect)
Cursor IDE Windsurf IDE VS Code IDE
> npx killer-skills add affaan-m/everything-claude-code/cpp-testing

Agent Capability Analysis

The cpp-testing MCP Server by affaan-m is an open-source Categories.official integration for Claude and other AI agents, enabling seamless task automation and capability expansion. Optimized for cpp-testing setup guide, C++ test automation with GoogleTest, how to use cpp-testing for C++ development.

Ideal Agent Persona

Ideal for C++ Development Agents requiring advanced testing capabilities with GoogleTest and CMake

Core Value

Empowers agents to write and configure comprehensive C++ tests using GoogleTest/GoogleMock, while integrating with CMake/CTest for consistent execution and adding coverage with sanitizers for memory and race diagnostics

Capabilities Granted for cpp-testing MCP Server

Writing new C++ unit tests with GoogleTest
Configuring CMake workflows for automated test execution
Diagnosing flaky tests and enabling memory sanitizers

! Prerequisites & Limits

  • Requires C++17/20 compatibility
  • Limited to GoogleTest and CMake frameworks
Project
SKILL.md
8.8 KB
.cursorrules
1.2 KB
package.json
240 B
Ready
UTF-8
SKILL.md
Readonly

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:

  1. RED: write a failing test that captures the new behavior
  2. GREEN: implement the smallest change to pass
  3. REFACTOR: clean up while tests stay green
cpp
1// tests/add_test.cpp 2#include <gtest/gtest.h> 3 4int Add(int a, int b); // Provided by production code. 5 6TEST(AddTest, AddsTwoNumbers) { // RED 7 EXPECT_EQ(Add(2, 3), 5); 8} 9 10// src/add.cpp 11int Add(int a, int b) { // GREEN 12 return a + b; 13} 14 15// REFACTOR: simplify/rename once tests pass

Code Examples

Basic Unit Test (gtest)

cpp
1// tests/calculator_test.cpp 2#include <gtest/gtest.h> 3 4int Add(int a, int b); // Provided by production code. 5 6TEST(CalculatorTest, AddsTwoNumbers) { 7 EXPECT_EQ(Add(2, 3), 5); 8}

Fixture (gtest)

cpp
1// tests/user_store_test.cpp 2// Pseudocode stub: replace UserStore/User with project types. 3#include <gtest/gtest.h> 4#include <memory> 5#include <optional> 6#include <string> 7 8struct User { std::string name; }; 9class UserStore { 10public: 11 explicit UserStore(std::string /*path*/) {} 12 void Seed(std::initializer_list<User> /*users*/) {} 13 std::optional<User> Find(const std::string &/*name*/) { return User{"alice"}; } 14}; 15 16class UserStoreTest : public ::testing::Test { 17protected: 18 void SetUp() override { 19 store = std::make_unique<UserStore>(":memory:"); 20 store->Seed({{"alice"}, {"bob"}}); 21 } 22 23 std::unique_ptr<UserStore> store; 24}; 25 26TEST_F(UserStoreTest, FindsExistingUser) { 27 auto user = store->Find("alice"); 28 ASSERT_TRUE(user.has_value()); 29 EXPECT_EQ(user->name, "alice"); 30}

Mock (gmock)

cpp
1// tests/notifier_test.cpp 2#include <gmock/gmock.h> 3#include <gtest/gtest.h> 4#include <string> 5 6class Notifier { 7public: 8 virtual ~Notifier() = default; 9 virtual void Send(const std::string &message) = 0; 10}; 11 12class MockNotifier : public Notifier { 13public: 14 MOCK_METHOD(void, Send, (const std::string &message), (override)); 15}; 16 17class Service { 18public: 19 explicit Service(Notifier &notifier) : notifier_(notifier) {} 20 void Publish(const std::string &message) { notifier_.Send(message); } 21 22private: 23 Notifier &notifier_; 24}; 25 26TEST(ServiceTest, SendsNotifications) { 27 MockNotifier notifier; 28 Service service(notifier); 29 30 EXPECT_CALL(notifier, Send("hello")).Times(1); 31 service.Publish("hello"); 32}

CMake/CTest Quickstart

cmake
1# CMakeLists.txt (excerpt) 2cmake_minimum_required(VERSION 3.20) 3project(example LANGUAGES CXX) 4 5set(CMAKE_CXX_STANDARD 20) 6set(CMAKE_CXX_STANDARD_REQUIRED ON) 7 8include(FetchContent) 9# Prefer project-locked versions. If using a tag, use a pinned version per project policy. 10set(GTEST_VERSION v1.17.0) # Adjust to project policy. 11FetchContent_Declare( 12 googletest 13 # Google Test framework (official repository) 14 URL https://github.com/google/googletest/archive/refs/tags/${GTEST_VERSION}.zip 15) 16FetchContent_MakeAvailable(googletest) 17 18add_executable(example_tests 19 tests/calculator_test.cpp 20 src/calculator.cpp 21) 22target_link_libraries(example_tests GTest::gtest GTest::gmock GTest::gtest_main) 23 24enable_testing() 25include(GoogleTest) 26gtest_discover_tests(example_tests)
bash
1cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug 2cmake --build build -j 3ctest --test-dir build --output-on-failure

Running Tests

bash
1ctest --test-dir build --output-on-failure 2ctest --test-dir build -R ClampTest 3ctest --test-dir build -R "UserStoreTest.*" --output-on-failure
bash
1./build/example_tests --gtest_filter=ClampTest.* 2./build/example_tests --gtest_filter=UserStoreTest.FindsExistingUser

Debugging Failures

  1. Re-run the single failing test with gtest filter.
  2. Add scoped logging around the failing assertion.
  3. Re-run with sanitizers enabled.
  4. Expand to full suite once the root cause is fixed.

Coverage

Prefer target-level settings instead of global flags.

cmake
1option(ENABLE_COVERAGE "Enable coverage flags" OFF) 2 3if(ENABLE_COVERAGE) 4 if(CMAKE_CXX_COMPILER_ID MATCHES "GNU") 5 target_compile_options(example_tests PRIVATE --coverage) 6 target_link_options(example_tests PRIVATE --coverage) 7 elseif(CMAKE_CXX_COMPILER_ID MATCHES "Clang") 8 target_compile_options(example_tests PRIVATE -fprofile-instr-generate -fcoverage-mapping) 9 target_link_options(example_tests PRIVATE -fprofile-instr-generate) 10 endif() 11endif()

GCC + gcov + lcov:

bash
1cmake -S . -B build-cov -DENABLE_COVERAGE=ON 2cmake --build build-cov -j 3ctest --test-dir build-cov 4lcov --capture --directory build-cov --output-file coverage.info 5lcov --remove coverage.info '/usr/*' --output-file coverage.info 6genhtml coverage.info --output-directory coverage

Clang + llvm-cov:

bash
1cmake -S . -B build-llvm -DENABLE_COVERAGE=ON -DCMAKE_CXX_COMPILER=clang++ 2cmake --build build-llvm -j 3LLVM_PROFILE_FILE="build-llvm/default.profraw" ctest --test-dir build-llvm 4llvm-profdata merge -sparse build-llvm/default.profraw -o build-llvm/default.profdata 5llvm-cov report build-llvm/example_tests -instr-profile=build-llvm/default.profdata

Sanitizers

cmake
1option(ENABLE_ASAN "Enable AddressSanitizer" OFF) 2option(ENABLE_UBSAN "Enable UndefinedBehaviorSanitizer" OFF) 3option(ENABLE_TSAN "Enable ThreadSanitizer" OFF) 4 5if(ENABLE_ASAN) 6 add_compile_options(-fsanitize=address -fno-omit-frame-pointer) 7 add_link_options(-fsanitize=address) 8endif() 9if(ENABLE_UBSAN) 10 add_compile_options(-fsanitize=undefined -fno-omit-frame-pointer) 11 add_link_options(-fsanitize=undefined) 12endif() 13if(ENABLE_TSAN) 14 add_compile_options(-fsanitize=thread) 15 add_link_options(-fsanitize=thread) 16endif()

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):

cpp
1#include <cstddef> 2#include <cstdint> 3#include <string> 4 5extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) { 6 std::string input(reinterpret_cast<const char *>(data), size); 7 // ParseConfig(input); // project function 8 return 0; 9}

Alternatives to GoogleTest

  • Catch2: header-only, expressive matchers
  • doctest: lightweight, minimal compile overhead

Related Skills

Looking for an alternative to cpp-testing or building a Categories.official AI Agent? Explore these related open-source MCP Servers.

View All

flags

Logo of facebook
facebook

flags is a feature flag management system that enables developers to check flag states, compare channels, and debug feature behavior differences across release channels.

243.6k
0
Design

extract-errors

Logo of facebook
facebook

extract-errors is a skill that assists in extracting and managing error codes in React applications using yarn extract-errors command.

243.6k
0
Design

fix

Logo of facebook
facebook

fix is a technical skill that resolves lint errors, formatting issues, and ensures code quality in declarative, frontend, and UI projects

243.6k
0
Design

flow

Logo of facebook
facebook

Flow is a type checking system for JavaScript, used to validate React code and ensure consistency across applications

243.6k
0
Design