test-implement: テスト実装（テストケースの具体化）

ISTQB/JSTQB のテストプロセス 7 活動のうち テスト実装（test implementation） を担う単機能スキル。 test-design が導出したテストケースを 実行できる形に具体化 する。対象に応じて分岐する:

• 自動テスト → テストコード・テストデータ・テストダブル（test double: モック/スタブ/フェイク）。 コンパイル/構文レベルの動作確認まで（テストランナーがケースを認識し、構文・型が通る状態）。
• 手動テスト → 手順書（test-procedures.md）・テストデータ・環境準備手順。

このスキルは テスト実装だけ を行う。テスト条件の識別（test-analyze）・テストケース設計 （test-design）・実行と結果解釈（test-execute）・レポート（test-report）は各専用スキルの担当で、 ここでは呼び出さない。テスト対象の検証としての実行（テストを走らせて対象の欠陥を見つける）は しない — それは test-execute の担当。ここでの「動作確認」は、書いたテスト自体が実行可能な 形になっているかの確認に限る。単発のテスト作成依頼（単にユニットテストを 1 つ書きたいだけ）は 対象外 — その場合は通常のコーディング支援で対応する。

このスキルが従う横断原則

testing-skills 全 8 スキル共通の原則。型は test-plan（参照実装）に揃える。

1. ファイル規約 + 任意入力

• 成果物の既定パスは対象に応じて分岐する:
  • 自動テスト → プロジェクトのテストコード配置規約に従った場所（src/test/・tests/・ __tests__/ 等）。テストデータ・ダブルもその規約に置く。
  • 手動テスト → docs/test/<テスト対象名>/test-procedures.md。
• プロジェクト側（CLAUDE.md / AGENTS.md 等）に配置規約・テスト規約があればそちらを優先する。 着手前にリポジトリを調べ、既存のテストコード構成・命名・フレームワークの慣習に合わせる。
• 前工程の成果物 test-case.md（既定 docs/test/<テスト対象名>/test-case.md）が規約パスに あれば 入力として読む。あわせて test-design.md（技法選定根拠・カバレッジ）・ test-plan.md があれば設計根拠・重点配分の参照にする。
• test-case.md が無ければ test-implement を進めず、/test-design <テスト対象名> の実行を 提案するに留める（前工程の成果物を代作しない）。

2. 調査優先 + 決定のみ質問

• 事実はリポジトリ調査で埋める。テストフレームワーク・ランナー・既存テストの書き方・ テストデータの置き方・ダブルの作り方・依存関係は、利用者に訊く前に自分で調べる。
• 利用者にしか決められない判断だけ を AskUserQuestion で確認する。test-implement では 主に 自動/手動の切り分け（曖昧なとき）・使用するフレームワークやライブラリの選択・ テストデータの生成方針 がこれに当たる（推奨案を先頭に添えて訊く）。
• 流れは 調査 → ドラフト提示 → 承認 → 規約パスへ書き込み。承認前に確定ファイルを書かない。

3. 改善提案と仕様反映（early testing 原則）

• 具体化中に見つけた テスト対象・仕様・テスタビリティの問題（テスト困難な構造、 観測不能な状態、DI できず差し替え不能な依存、非決定的な挙動など）は、成果物の 「改善提案」セクションで 提示 する。
• 起票前に既決事項を照合する。前工程成果物（test-plan / test-analysis / test-design）と プロジェクトのメモリに同じ問題が既に記録され、対応先（詳細設計送り・作業計画送り等）が 確定しているものは改善提案に 再掲しない。必要なら「次のステップ」欄の参照 1 行に留める。 改善提案には この工程で新規に見つけた未解決の問題だけ を載せる。
• 仕様の穴は提示で終わらせない。具体化の過程で仕様の曖昧さ・矛盾が割れた場合は、利用者の 決定を AskUserQuestion で確認し、決定が出たら その内容を仕様書へ反映する作業まで行う （反映先の仕様書が規約パスにある場合）。テスト困難な構造・差し替え不能な依存のような 実装レベルで解決すべき決定は、仕様書ではなく作業計画・メモリ等へ退避する。
• 反映が済んだ提案は「改善提案」セクションから削除する（「反映済み」注記で残さない。 決定の記録は仕様書の改訂履歴が担う）。全提案が解消したらセクションごと削除して番号を詰め、 未解決の提案が残っている間だけセクションを維持する。
• スキル自身がテスト対象のコードを修正しない。テストを通すために対象コードを書き換える 誘惑があるが、それは early testing（早期に欠陥を見つけて指摘する）の範囲を超える。指摘に留める。

4. 単機能の堅持

• test-implement は テスト実装の成果物だけ を作る。他スキルを呼び出さず、相互参照もしない。
• 次工程が必要なら、成果物末尾で 次に /test-execute を実行することを提案 するに留める （代わりに実行・結果解釈を進めない）。

5. Progressive disclosure

• 本文は簡潔に保ち、テンプレ・詳細は references/ に置く。
• 手動テスト手順書テンプレ: references/template.md（test-procedures.md の雛形）。

6. 成果物の記述スタイル

Markdown 成果物（test-procedures.md・改善提案等）に適用する。テストコード自体は プロジェクトのコード規約・周囲の既存テストの書き方に従う（手順 3a）。

• 略号・コードネームを定義なしで使わない（例: 仕様書内の G3 のような社内略号）。 初出で正式名称・意味を併記するか、平易な表現に開く。成果物単体で読み返して意味が 取れることを基準にする。
• スキルの実行記録を成果物に含めない。利用者との Q&A ログ・フェーズ別実行時間などは 対話のテレメトリであって、レビュー対象の内容ではない。利用者との決定事項は本文の該当箇所 （根拠・凡例等）へ埋め込み、実行記録が必要なら scratchpad 等へ分離する。

手順

手順 0: テスト対象の確定

• 引数 <テスト対象名> があればそれを対象名とする。無ければ利用者に一言で確認する。 対象名は成果物パス docs/test/<テスト対象名>/ のディレクトリ名にも使う（英数字・ハイフンへ正規化）。

手順 1: 前工程成果物の読み込みと調査

原則 1・2 に従う:

• test-case.md を読む。規約パスに無ければ /test-design の実行を提案して停止（代作しない）。
• プロジェクトのテスト環境を調査: 使用フレームワーク（JUnit / pytest / Jest / go test 等）・ ランナー・既存テストの配置と命名・テストデータの置き方・テストダブルの作り方・CI でのテスト実行方法。

手順 2: 自動/手動区分の検証

test-case.md の各ケースには test-design が付けた 区分（自動/手動） がある。それを入力として 読み、実装の観点で検証する:

• 区分どおり実装できるならそのまま従う。区分列が無い古い成果物なら、ここで切り分ける （自動向き: 入出力が明確・環境で再現可能・回帰テストにしたい / 手動向き: UI/UX や探索的な 確認・自動化コストが見合わない・人間の主観判断が要る）。
• 実装時に食い違いが判明したら test-case.md の区分を更新して正とする（例: 自動と されていたが依存を差し替えられず手動へ、手動とされていたがローカル環境で自動化できた）。 更新理由を利用者へ報告する。
• 切り分けが利用者依存で曖昧なら、原則 2 に従い AskUserQuestion（推奨案先頭）で確認する。

分岐後、それぞれ手順 3a / 3b へ進む。両方混在する場合は両方を実施する。

手順 3a: 自動テストの具体化

• test-case.md のケースをテストコードに落とす。プロジェクトの規約・フレームワークに厳密に合わせ、 周囲の既存テストと同じ書き方（命名・構造・アサーション作法）にする。
• テストデータ を用意する（フィクスチャ・ファクトリ・パラメタライズ入力）。
• テストダブル（test double）が必要なら用意する（モック/スタブ/フェイク。差し替え対象と理由を明記）。
• コンパイル/構文レベルの動作確認まで行う: テストランナーがケースを収集でき、構文・型が通る状態を確認する （例: --collect-only / dry-run / type-check / compile のみ）。 テスト対象の検証としての本実行（pass/fail を判定して欠陥を探す）はしない（原則: それは test-execute）。

手順 3b: 手動テストの具体化

• references/template.md の構成で test-procedures.md を作る。
• 各手順は 前提条件・手順（番号付き）・入力データ・期待結果 を、実施者が迷わない粒度で書く。
• テストデータ（投入値・アカウント・初期状態など）と 環境準備手順（セットアップ・ テストデータ投入・後片付け）を添える。

手順 4: ドラフト提示 → 承認 → 書き込み

• 自動: 追加/変更するテストコード・データ・ダブルを 本文で提示して承認を得る（原則 2）。 承認後、プロジェクト規約のテストコード配置場所へ書き込み、手順 3a の動作確認結果を報告する。
• 手動: test-procedures.md のドラフトを提示して承認を得て、規約パスへ書き込む。
• 手順 1〜3 で見つけたテスタビリティ等の問題は「改善提案」に記載（原則 3）。
• 末尾で 次工程 /test-execute <テスト対象名> の実行を提案 する（原則 4）。自分では実行しない。

手順 5: 終了条件の確認と完了宣言

テスト実装の終了条件（exit criteria）は以下。利用者に「終わりか」と訊かれる前に、 スキル側で判定して宣言する:

1. test-case.md の全ケースが区分（自動/手動）どおりに具体化済み（手順 3a / 3b）。
2. 自動テストはランナーがケースを収集でき、構文・型が通ることを確認済み（手順 3a）。
3. 区分の食い違いは test-case.md を更新して解消済み（手順 2）。
4. 承認済みの成果物（テストコード / test-procedures.md）が規約パスへ書き込み済み（手順 4）。
5. 改善提案が空（各提案が仕様反映・対応先確定のいずれかで解消済み）。
6. test-review ゲート: /test-review <テスト対象名> implement の判定が「通過」または 「条件付き通過」（記録 test-review-implement.md）になっている、もしくは利用者がゲートの スキップを明示している。未実施なら完了宣言せず、利用者へ実行を促す （test-review は明示起動のみで、本スキルからは起動できない）。

• 全て満たしたら 「テスト実装は完了」と明言 し、/test-execute <テスト対象名> の提案で 閉じる（原則 4）。
• 満たしていない項目があれば、何が残っているかを列挙して先へ進めない。

用語（JSTQB 訳語 / 初出英語併記）

• テスト実装（test implementation）: テストケースを実行できる形に具体化する活動。
• テストダブル（test double）: 依存を置き換える代用物の総称（モック/スタブ/フェイク等）。
• テストデータ（test data）: テスト実行時に投入する入力・初期状態のデータ。
• テスト手順書（test procedure）: 手動実行の前提・手順・入力・期待結果を記した文書。