菜单
実 DB を起動して Handler → Usecase → Service → Repository を貫通させる integration test を書く。fixture 分離、TestMain/global setup、トランザクション単位のロールバックによるテスト間隔離、API エンドポイントを HTTP 経由で叩く E2E 的検証を扱う。単体テスト(mock 前提)は対象外で `backend-test-writer` に委譲する。「integration test 書いて」「E2E テスト追加して」「DB 込みのテスト書いて」などで起動。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
docs/spec/ の仕様書を元に、docs/work/YYYYMMDD_<feature>.md として実装計画書を作成する。Phase 分解・影響範囲・テスト戦略・リスクを構造化し、実装前にユーザー承認を取る。「実装計画立てて」「work 書いて」「どう進めるか計画して」などで起動。
差分や指定コードを構造化されたレビュー観点（正確性・設計・テスト・可読性・セキュリティ）で読み、優先度付きで指摘する。修正は提案するが勝手に書き換えない。「レビューして」「コードレビュー」「セカンドオピニオン」などで起動。
未知のコードベースを最短で把握するための構造化探索を行う。言語・ビルドツール・アーキテクチャ・テスト方針・主要なエントリポイントを短時間でレポート化する。「このプロジェクト教えて」「コードベース調べて」「初見で入ったから概要ほしい」などで起動。
未コミットの変更を依存関係と関心事に基づいて適切な粒度のコミットに分割する。自動生成物・手動実装・テスト・ドキュメントを分離し、レビューしやすい履歴を作る。「コミット分けて」「良い粒度でコミット」「この変更コミットにして」などで起動。
バグ調査を場当たり的でなく体系的に進める。再現→仮説→検証→修正→回帰テストの順序を守り、仮説と事実を分けて記録する。「バグ調査して」「なぜか動かない」「デバッグ手伝って」などで起動。
汎用的な開発オーケストレーター。docs/spec/ の仕様と docs/work/ の実装計画書を軸に、Phase 分解と PDCA サイクルで実装を進める。自分は実装せず、各 Phase を Task で専門 agent / Explore / Plan に委託する。「開発進めて」「実装オーケストレートして」「機能実装して」などで起動。
| name | backend-integration-test-writer |
| description | 実 DB を起動して Handler → Usecase → Service → Repository を貫通させる integration test を書く。fixture 分離、TestMain/global setup、トランザクション単位のロールバックによるテスト間隔離、API エンドポイントを HTTP 経由で叩く E2E 的検証を扱う。単体テスト(mock 前提)は対象外で `backend-test-writer` に委譲する。「integration test 書いて」「E2E テスト追加して」「DB 込みのテスト書いて」などで起動。 |
実 DB(および必要な外部サービスのコンテナ)を起動した状態で、アプリケーション層を なるべく mock なしで 貫通させるテストを書く。単体テスト(mock 前提)と役割を分ける:
backend-test-writer最も重要。勝手に独自構造を作らない。
test/integration/ があればその中を一通り ls して構成を把握Read し、以下を抽出:
既存パターンがなければ以下の雛形を提案する(プロジェクトで合意後に採用)。
test/
├── integration/ # integration test 本体
│ ├── main_test.go / setup.ts # TestMain / 共通初期化
│ ├── <feature>_test.* # 機能ごとのテスト
│ ├── util/ # HTTP ヘルパー・DI・context
│ └── fixture/
│ ├── master/ # マスターデータ定義
│ └── user/ # 各テストユーザー用データ
└── scenario/ # 任意: より広い E2E シナリオ(長めの流れ)
fixture/ は「どのテストでも共通して必要になるデータ」を宣言的に定義する層。個別テストで必要になる細かいデータはテスト関数内で作るほうが保守しやすい。
選択肢(既存に合わせる、なければプロジェクトで選ぶ):
| 方式 | 速度 | 実装難度 | 使い所 |
|---|---|---|---|
| トランザクション rollback | ◎ | △ (トランザクション境界を跨ぐ API だと難) | 書き込み系テストが多いとき |
| テーブル truncate | ○ | ○ | シンプル、小規模 |
| テストごとに DB スキーマ再作成 | ✕ | ◎ | 本数が少ないとき |
推奨: トランザクション rollback。fixture を TestMain で一度だけ投入しておき、各テストの最外層トランザクションはテスト完了時に必ずロールバックする。本体 API が内部で開くトランザクションは、この外側トランザクションに乗る形にする(ネストしたトランザクションを再利用する実装か、テスト時のみ外側のトランザクションを注入できる DI が必要)。
test-user-001 / test-user-002 のように テストごとにユーザー ID を変えるtime.Unix(0, 0) / 定数 ID)fixture は proto からの自動生成で用意してもよいし、手書き helper でもよい。テスト本体から fixture 投入コードが見えるようにする(fixture が暗黙でロードされると、何に依存しているか追いにくい)。
E2E で貫通させるため、Service や Repository を直接呼ばない。プロジェクトの HTTP 境界を経由する。プロジェクトの API スタイルに応じて:
bufconn 相当)を立ててクライアント呼び出しで貫通させる本番と同じ middleware を通すことが理想(認証 middleware は test 用のバイパスを用意)。
2 段階で見る:
レスポンスだけ見て満足しない — handler が書いた値が DB に反映されているかまで見ないと「成功っぽいレスポンスを返すだけ」のバグを見逃す。
docker-compose up -d db で Postgres を起動 → テスト実行(Makefile の make test-integration などの形に統一)services: で Postgres コンテナを起動して DATABASE_URL を渡すtime.Now() 直叩き)— clock を注入 or 固定値でシード具体の実装は既存パターン最優先。参考までに:
func TestXxx(t *testing.T) + httptest.NewRecorder() / http.ServeMux.ServeHTTP()。-tags=integration などの build tag で単体テストと分離し go test -tags=integration ./test/integration/... で実行describe / it + pg 直接接続 / drizzle client。test/integration/*.test.ts パスで分離し vitest run test/integration で実行pytest + testcontainers、conftest.py で fixturebackend-test-planner → backend-test-writer + backend-integration-test-writer を順に回す