affaan-m/ECC/docs/ja-JP/skills/cpp-testing/SKILL.md
cpp-testing
Use it for testing tasks; the detail page covers purpose, installation, and practical steps.
- Source repository stars
- 234,327
- Declared platforms
- 0
- Static risk flags
- 2
- Last source update
- 2026-07-27
- Source checked
- 2026-07-28
Decision brief
What it does—and where it fits
CMake/CTest を使用した GoogleTest/GoogleMock による最新の C++(C++17/20)向けのエージェント重視のテストワークフローです。
Not for
- Tasks that require unconfirmed production actions or broad system permissions.
- Environments where the pinned source and install steps cannot be inspected.
Compatibility matrix
Platform support, with evidence labels
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
Inspect first. Install second.
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/affaan-m/ECC --skill "docs/ja-JP/skills/cpp-testing"Inspect the Agent Skill "cpp-testing" from https://github.com/affaan-m/ECC/blob/4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38/docs/ja-JP/skills/cpp-testing/SKILL.md at commit 4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
What the source asks the agent to do
- 01
使用タイミング
新しい C++ テストの作成または既存のテストの修正
新しい C++ テストの作成または既存のテストの修正C++ コンポーネントのユニット/統合テストカバレッジの設計テストカバレッジ、CI ゲーティング、リグレッション保護の追加 - 02
使用すべきでない場合
テスト変更を伴わない新しい製品機能の実装
テスト変更を伴わない新しい製品機能の実装テストカバレッジや失敗に関連しない大規模なリファクタリング検証するテストリグレッションのないパフォーマンスチューニング - 03
コア概念
TDD ループ: red → green → refactor(テスト優先、最小限の修正、その後クリーンアップ)
TDD ループ: red → green → refactor(テスト優先、最小限の修正、その後クリーンアップ)分離: グローバル状態よりも依存性注入とフェイクを優先テストレイアウト: tests/unit、tests/integration、tests/testdata - 04
TDD ワークフロー
RED → GREEN → REFACTOR ループに従います:
RED: 新しい動作をキャプチャする失敗するテストを書くGREEN: 合格する最小限の変更を実装するREFACTOR: テストがグリーンのままクリーンアップする - 05
コード例
Review the “コード例” section in the pinned source before continuing.
Review and apply the “コード例” source section.
Permission review
Static risk signals and limitations
Network access
The documentation includes network, browsing, or remote request actions.
URL Google Test framework (official repository) https://github.com/google/googletest/archive/refs/tags/${GTEST_VERSION}.zipWrites files
The documentation asks the agent to create, modify, or delete local files.
lcov --remove coverage.info '/usr/*' --output-file coverage.infoEvidence record
Why each signal appears
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 73/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 234,327 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Provenance and original SKILL.md
- Repository
- affaan-m/ECC
- Skill path
- docs/ja-JP/skills/cpp-testing/SKILL.md
- Commit
- 4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38
- License
- MIT
- Collected
- 2026-07-28
- Default branch
- main
View the original SKILL.md
C++ Testing(エージェントスキル)
CMake/CTest を使用した GoogleTest/GoogleMock による最新の C++(C++17/20)向けのエージェント重視のテストワークフローです。
使用タイミング
- 新しい C++ テストの作成または既存のテストの修正
- C++ コンポーネントのユニット/統合テストカバレッジの設計
- テストカバレッジ、CI ゲーティング、リグレッション保護の追加
- 一貫した実行のための CMake/CTest ワークフローの設定
- テスト失敗またはフレーキーな動作の調査
- メモリ/レース診断のためのサニタイザーの有効化
使用すべきでない場合
- テスト変更を伴わない新しい製品機能の実装
- テストカバレッジや失敗に関連しない大規模なリファクタリング
- 検証するテストリグレッションのないパフォーマンスチューニング
- C++ 以外のプロジェクトまたはテスト以外のタスク
コア概念
- TDD ループ: red → green → refactor(テスト優先、最小限の修正、その後クリーンアップ)
- 分離: グローバル状態よりも依存性注入とフェイクを優先
- テストレイアウト:
tests/unit、tests/integration、tests/testdata - モック vs フェイク: 相互作用にはモック、ステートフルな動作にはフェイク
- CTest ディスカバリー: 安定したテストディスカバリーのために
gtest_discover_tests()を使用 - CI シグナル: 最初にサブセットを実行し、次に
--output-on-failureでフルスイートを実行
TDD ワークフロー
RED → GREEN → REFACTOR ループに従います:
- RED: 新しい動作をキャプチャする失敗するテストを書く
- GREEN: 合格する最小限の変更を実装する
- REFACTOR: テストがグリーンのままクリーンアップする
// tests/add_test.cpp
#include <gtest/gtest.h>
int Add(int a, int b); // プロダクションコードによって提供されます。
TEST(AddTest, AddsTwoNumbers) { // RED
EXPECT_EQ(Add(2, 3), 5);
}
// src/add.cpp
int Add(int a, int b) { // GREEN
return a + b;
}
// REFACTOR: テストが合格したら簡素化/名前変更
コード例
基本的なユニットテスト(gtest)
// tests/calculator_test.cpp
#include <gtest/gtest.h>
int Add(int a, int b); // プロダクションコードによって提供されます。
TEST(CalculatorTest, AddsTwoNumbers) {
EXPECT_EQ(Add(2, 3), 5);
}
フィクスチャ(gtest)
// tests/user_store_test.cpp
// 擬似コードスタブ: UserStore/User をプロジェクトの型に置き換えてください。
#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");
}
モック(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 クイックスタート
# CMakeLists.txt(抜粋)
cmake_minimum_required(VERSION 3.20)
project(example LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
include(FetchContent)
# プロジェクトロックされたバージョンを優先します。タグを使用する場合は、プロジェクトポリシーに従って固定されたバージョンを使用します。
set(GTEST_VERSION v1.17.0) # プロジェクトポリシーに合わせて調整します。
FetchContent_Declare(
googletest
URL Google Test framework (official repository) 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-failure
テストの実行
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.FindsExistingUser
失敗のデバッグ
- gtest フィルタで単一の失敗したテストを再実行します。
- 失敗したアサーションの周りにスコープ付きログを追加します。
- サニタイザーを有効にして再実行します。
- 根本原因が修正されたら、フルスイートに拡張します。
カバレッジ
グローバルフラグではなく、ターゲットレベルの設定を優先します。
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 coverage
Clang + 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.profdata
サニタイザー
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()
フレーキーテストのガードレール
- 同期に
sleepを使用しないでください。条件変数またはラッチを使用してください。 - 一時ディレクトリをテストごとに一意にし、常にクリーンアップしてください。
- ユニットテストで実際の時間、ネットワーク、ファイルシステムの依存関係を避けてください。
- ランダム化された入力には決定論的シードを使用してください。
ベストプラクティス
すべきこと
- テストを決定論的かつ分離されたものに保つ
- グローバル変数よりも依存性注入を優先する
- 前提条件には
ASSERT_*を使用し、複数のチェックにはEXPECT_*を使用する - CTest ラベルまたはディレクトリでユニットテストと統合テストを分離する
- メモリとレース検出のために CI でサニタイザーを実行する
すべきでないこと
- ユニットテストで実際の時間やネットワークに依存しない
- 条件変数を使用できる場合、同期としてスリープを使用しない
- 単純な値オブジェクトをオーバーモックしない
- 重要でないログに脆弱な文字列マッチングを使用しない
よくある落とし穴
- 固定一時パスの使用 → テストごとに一意の一時ディレクトリを生成し、クリーンアップします。
- ウォールクロック時間への依存 → クロックを注入するか、偽の時間ソースを使用します。
- フレーキーな並行性テスト → 条件変数/ラッチと境界付き待機を使用します。
- 隠れたグローバル状態 → フィクスチャでグローバル状態をリセットするか、グローバル変数を削除します。
- オーバーモック → ステートフルな動作にはフェイクを優先し、相互作用のみをモックします。
- サニタイザー実行の欠落 → CI に ASan/UBSan/TSan ビルドを追加します。
- デバッグのみのビルドでのカバレッジ → カバレッジターゲットが一貫したフラグを使用することを確認します。
オプションの付録: ファジングとプロパティテスト
プロジェクトがすでに LLVM/libFuzzer またはプロパティテストライブラリをサポートしている場合にのみ使用してください。
- libFuzzer: 最小限の I/O で純粋関数に最適です。
- RapidCheck: 不変条件を検証するプロパティベースのテストです。
最小限の libFuzzer ハーネス(擬似コード: 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); // プロジェクト関数
return 0;
}
GoogleTest の代替
- Catch2: ヘッダーオンリー、表現力豊かなマッチャー
- doctest: 軽量、最小限のコンパイルオーバーヘッド
Alternatives
Compare before choosing
affaan-m/ECC
cpp-testing
Use only when writing/updating/fixing C++ tests, configuring GoogleTest/CTest, diagnosing failing or flaky tests, or adding coverage/sanitizers.
affaan-m/ECC
cpp-testing
Use only when writing/updating/fixing C++ tests, configuring GoogleTest/CTest, diagnosing failing or flaky tests, or adding coverage/sanitizers.
affaan-m/ECC
cpp-testing
Use it for testing tasks; the detail page covers purpose, installation, and practical steps.
coreyhaines31/marketingskills
ab-testing
When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program