cpp-testing

cpp-testing スキルの概要

cpp-testing スキルは、GoogleTest/GoogleMock、CMake、CTest を中心にした実践的なワークフローで、C++ テストの作成・実行・デバッグを支援します。新しいカバレッジの追加、フレイキーなテストの安定化、モダン C++ コード向けの再現性あるテストハーネスの構築が必要な人に最適で、一般的な C++ 機能実装向けではありません。

cpp-testing は何のためのものか

cpp-testing スキルは、テストをより信頼できるもの、より役立つものにする作業で使います。たとえば、新しいユニットテスト、統合テスト、回帰テストの追加、失敗テストの切り分け、サニタイザを使ったデバッグなどです。主な価値は、テスト設計と実行に関する意思決定を支援することにあります。特に、モック、フェイク、テストフィクスチャ、CTest 主導の実行のどれを選ぶべきか判断したいときに効きます。

どんな人に向いているか

この cpp-testing skill は、C++ 開発者、ビルドシステムの管理者、そしてすでに GoogleTest/CTest を使っている、または採用できるリポジトリで作業するエージェントに向いています。タスク説明が曖昧でも、明らかにテスト関連だと分かる場合に特に有用です。たとえば、「フレイキーなスイートを直して」「このモジュールのカバレッジを追加して」「このバグを CI で早く検知できるようにして」といった依頼です。

何が違うのか

汎用的なプロンプトと比べると、cpp-testing はテストファースト寄りの、より絞られたワークフローを提示します。つまり、いつ使うか、いつ使わないか、どうテストを構成するか、CI に向いた形でどう実行するかが明確です。そのため cpp-testing guide は、広い意味での「テストを書いて」という依頼よりも Test Automation に対して実行可能な指示になりやすく、分離性・見つけやすさ・最小限で再現可能な検証を重視する方向に寄ります。

cpp-testing スキルの使い方

cpp-testing をインストールする

cpp-testing スキルは次のコマンドでインストールします。

npx skills add affaan-m/everything-claude-code --skill cpp-testing

そのあと、C++ プロジェクトが入っているリポジトリをエージェントに指示します。このスキルは、変更提案の前に実際のビルドファイル、テスト構成、既存の規約を確認できるときに最も効果を発揮します。

まず読むべきファイルを見極める

最初に SKILL.md を読み、次に README.md、AGENTS.md、metadata.json、そして存在するなら rules/、references/、resources/、scripts/ フォルダを確認します。このリポジトリでは SKILL.md が唯一のソースファイルなので、最初の流れはシンプルです。スキルを読んだうえで、その助言を自分のプロジェクトの CMakeLists.txt、テストディレクトリ、CI 設定に当てはめます。

使いやすいタスクプロンプトを与える

良い cpp-testing usage プロンプトには、対象コード、失敗の症状、望むテストレベル、制約を含めます。たとえば「Parser::parseConfig() の GoogleTest カバレッジを追加して。テストは deterministic に保ち、ファイルシステム依存を避け、CMake/CTest で CI 上でも実行できるようにして」のように書きます。これだけの文脈があれば、ユニットテスト、統合テスト、モック、フィクスチャのどれを使うべきかをスキルが判断しやすくなります。

テストのワークフローに沿って進める

このスキルは、red-green-refactor の補助として使います。まず挙動を定義し、失敗するテストを書き、通すために最小限のコード変更を加え、その後でテストの形を整えます。フレイキーなテストの場合は、まずどの非決定性が原因になりそうかを特定してもらい、そのうえで CTest で失敗中のテストだけに絞ってから、必要に応じて全体スイートへ戻します。診断用途では、アサーション、ログ、サニタイザの案内、CI のゲート条件のどれが欲しいかも明示するとよいです。

cpp-testing スキル FAQ

cpp-testing は GoogleTest プロジェクト専用ですか？

いいえ。GoogleTest/GoogleMock が基本の相性ですが、基盤が CMake/CTest の C++ プロジェクトで、構造化されたテスト実行が必要なら cpp-testing スキルは広く使えます。周辺リポジトリに別のツールが載っていても問題ありません。逆に、C++ ではない、あるいは意味のあるテスト境界がないプロジェクトなら、選ぶべきスキルではない可能性が高いです。

いつ cpp-testing を使わないべきですか？

テスト変更を伴わない機能実装、テスト駆動ではない大規模リファクタリング、非 C++ リポジトリには使わないでください。さらに、主目的がパフォーマンス調整で、作業の軸になるテスト失敗・回帰・正しさ確認がない場合も、cpp-testing guide は適しません。

普通のプロンプトより優れていますか？

多くの場合はそうです。ただし、目的がコード生成そのものではなくテスト実行の品質向上であるときに限ります。cpp-testing skill は、分離性、テスト配置、CTest の使い方に対して意見のあるガードレールを追加するため、テストの構成方法や失敗の再現方法をエージェントが判断しやすくなります。

初心者にも使いやすいですか？

はい。ただし、対象コードと確認したい挙動を説明できることが前提です。具体例、失敗しているテスト名、小さな CMake ターゲットを渡せると特に役立ちます。一方で、「テストをもっと良くして」というだけの依頼では、あまり力を発揮しません。

cpp-testing スキルを改善する方法

入力をもっと具体的にする

cpp-testing の出力を改善する最善策は、対象、期待挙動、制約を最初から明確に与えることです。良い入力には、クラス名や関数名、必要なテストの種類、そして「ネットワーク禁止」「sleep 不可」「CTest で動作必須」「テストは hermetic に保つ」といった厳しい制約を含めます。

まずは最小の検証可能な変更を依頼する

cpp-testing skill は、狭く切った最初の一手を依頼したときに最もよく働きます。たとえば、失敗するテスト 1 本、バグ修正 1 件、サニタイザ実行 1 回、CI 対応のコマンド列 1 本といった単位です。そうすると差分が見やすくなり、テストハーネスの過剰設計も避けやすくなります。

ありがちな失敗パターンに注意する

主な失敗パターンは、過剰なモック化、見えない共有状態、そしてローカルでは通るのに CTest や CI では落ちるテストです。最初の結果が弱いと感じたら、実際のテストエントリポイント、現在のフィクスチャ設定、観測した失敗出力を追加して、推測ではなく証拠から判断できるように再依頼します。

1 回目の実行後に反復する

最初の結果を使ってスコープを絞り込みます。テストが脆いなら、より分離されたフィクスチャを求めます。浅すぎるなら、エッジケースや回帰カバレッジを追加します。遅いなら、まず一部だけを実行する計画を依頼します。cpp-testing for Test Automation では、この反復ループこそが品質向上の大きな源になることが多いです。