test-implement

---
name: test-implement
description: ISTQB/JSTQB のテスト実装（test implementation）活動を支援するスキル。test-design が導出したテストケースを、実行できる形に具体化する。自動テストなら実行手順（テストコード・テストデータ・テストダブル）をコンパイル/構文レベルの動作確認まで、手動テストなら手順書・テストデータ・環境準備手順を作る。「テストケースを実装して」「テストコードに落として」「テスト手順書を作って」「テストデータ・モックを用意して」と依頼されたときに使う。テスト対象の検証としての実行（結果の解釈・欠陥候補整理）は test-execute の担当でここではしない。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-implement <テスト対象名> で明示的に呼び出されたときのみ使用する。
license: MIT
disable-model-invocation: true
user-invocable: true
argument-hint: "[テスト対象名]"
---

# 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`](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`](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）: 手動実行の前提・手順・入力・期待結果を記した文書。

• SKILL.md 14 KB
• references/template.md 2 KB