# Testing

> テストピラミッド・テスト設計・品質戦略を整理する判断軸。テストの粒度・スコープ・優先順位に迷ったときに使う。TDDの具体的な実装手順は developer-specialist と併用する。

- Skill: `mae616/testing` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mae616/testing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mae616/testing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mae616 (https://skillmd.com/u/mae616)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/mae616/testing

---


# Testing Skill

## 発火条件
- テスト戦略・テスト設計・テストの粒度/スコープについて相談があった場合に適用する。
- 新規機能実装時のテスト計画、テストリファクタリング、CI/CDでのテスト最適化にも適用。
- TDDの具体的な実装手順は `developer-specialist` と併用する。

## このSkillの基本方針
- テストピラミッド: Unit > Integration > E2E の比率を守る。上層は少なく、下層は厚く。
- 最小主義: 最初は再現・境界・不変条件のみ。実装の写経になるほど増やさない。
- 既存優先: テスト雛形・命名規約・ヘルパーは既存パターンから再利用する。

## 思想（判断ルール）
1. **ユーザー視点**: テストはユーザーに見える振る舞いを検証する。実装詳細（private関数・内部状態）に依存しない。
2. **テストピラミッドを意識**: Unitテストを土台にし、Integrationで結合点を確認し、E2Eは重要フローのみ。逆三角形（E2E過多）を避ける。
3. **テストは最小で最大の安心**: 境界条件（null/空/最大/異常）と不変条件を押さえれば十分。網羅性の追求で保守コストを上げない。
4. **テストも負債になる**: 壊れやすいテスト・遅いテスト・意図不明なテストは技術的負債。定期的に見直す。

## テストピラミッドの判断基準

```
        /  E2E  \        ← 少なく。重要なユーザーフローのみ
       / Integration \    ← API境界・DB・外部サービス結合点
      /    Unit Tests   \ ← 厚く。ロジック・計算・変換・バリデーション
```

| 層 | 対象 | 速度 | 安定性 | 量 |
|----|------|------|--------|-----|
| **Unit** | 純粋関数、ロジック、バリデーション | 速い | 高い | 多い |
| **Integration** | API、DB、外部サービス連携 | 中程度 | 中程度 | 中程度 |
| **E2E** | ユーザーの重要フロー（ログイン→購入等） | 遅い | 低い | 少ない |

## テスト設計の原則

### 何をテストするか
- **境界条件**: null、空文字、0、最大値、負数、型境界
- **不変条件**: 「この条件は常に成立する」というビジネスルール
- **エラーパス**: 異常入力、ネットワーク障害、タイムアウト
- **状態遷移**: 重要な状態の変化（認証状態、フォーム送信等）
- **方式変更時は「無いべきものが無い」側も守る**: リファクタで実装方式を変えると、それまで「たまたまそうだった」性質（例: リソースの収録範囲、データの形）が仕組みの生命線に昇格することがある。既存テストは「在るべきものが在る」しか守っていないことが多いので、方式変更時は不変条件をガードするテストを追加する

### 何をテストしないか
- 実装詳細（private関数のテスト、内部状態の直接検証）
- フレームワーク/ライブラリ自体の動作
- 外部サービスの可用性（モックで代替）
- 全パスの網羅（コストに見合わない場合）

### テストの命名
```
// 良い例: 「何が」「どうなったとき」「どうなるか」
test("ユーザー登録_メールが空のとき_バリデーションエラーを返す")
test("カート_商品追加_合計金額が更新される")

// 悪い例: 実装詳細に依存
test("validateEmail関数がfalseを返す")
```

## 出力フォーマット（必ずこの順）
1. テスト方針（何をどの粒度でテストするか）
2. 理由（リスク / コスト / 保守性のバランス）
3. テスト設計（テストケース一覧 / 境界条件 / モック戦略）
4. TDDステップ（RED→GREEN→REFACTORの具体的手順）
5. チェックリスト（実装前に確認）
6. 落とし穴（避けるべき）

## チェックリスト
- [ ] RED→GREEN→REFACTOR の順序が守られているか（テストが先）
- [ ] テストはユーザー視点の振る舞いを検証しているか（実装詳細に依存していないか）
- [ ] 境界条件（null/空/最大/異常）が最低限押さえられているか
- [ ] テストピラミッドの比率が適切か（E2Eに偏っていないか）
- [ ] テストが独立しているか（他のテストの実行順に依存していないか）
- [ ] テスト名が「何が・どうなったとき・どうなるか」を表しているか
- [ ] モック/スタブの範囲が最小限か（過度なモックは信頼性を下げる）

## よくある落とし穴
- テストが「実装の写経」になり、安心が増えていない（ロジックのコピペ検証）
- E2Eテストを大量に書いて、CIが遅くなり開発体験が悪化する
- モックを使いすぎて、結合時に初めて問題が発覚する
- テストカバレッジの数値目標を追い、意味のないテストが増える
- `sleep` / 固定待機でテストを安定させようとする（根本原因を隠す）
- テストデータが共有されていて、テスト順序で結果が変わる
- `vite.config` にランタイム系プラグイン（エッジ実行環境系等）があると、テストランナーが環境設定の衝突で起動失敗する。テスト専用設定ファイルを分離し、プラグインなしの軽量環境でユニットテストを回す（ランタイム結合の確認は開発サーバー/プレビューに寄せる）