アンチパターン⑥「テスト省略」
AI開発の落とし穴:「動いたからテスト不要」
vibe codingで最も多い誤解の一つがこれです。
「AIが生成したコードは、動作確認したからテスト不要」
この考えは、致命的な誤り です。
なぜテストを省略するのか
vibe coderがテストを省略する理由があります。
理由1: 時間の節約
- テストを書く時間がもったいない
- その時間で新機能を作れる
理由2: AIへの過信
- 「AIが正しいコードを書いたはず」
- 「エラーが出なかったから大丈夫」
理由3: テストの書き方が分からない
- vibe coderの多くは非技術者
- テストの概念自体を知らない
理由4: 目の前の動作確認で満足
- ブラウザで動いた
- それで十分だと思う
AI開発でテストがない世界の危険性
テストがないコードベースで何が起きるか見てみましょう。
シナリオ:
Day 1: 機能Aを実装、動作確認OK
Day 3: 機能Bを追加、動作確認OK
Day 7: 機能Cを追加、動作確認OK
Day 10: 機能Dを追加、動作確認OK
Day 14: 機能Aが動かなくなっている
→ いつから?なぜ?
Day 15-30: デバッグ地獄
テストがあれば、機能BやCを追加した時点で、機能Aの破壊に気づけたはずです。
AI生成コードのリグレッションの恐怖
リグレッション とは、以前動いていた機能が動かなくなることです。
vibe codingでは、リグレッションが頻発します。
理由:
- AIは既存コードを理解していない
- 変更の影響範囲を把握していない
- 「新しい機能」に集中し、既存機能を壊す
テストがなければ、リグレッションに気づくのは ユーザーからの報告 になります。
AIにテストを書かせる
「テストを書く時間がない」なら、AIにテストを書かせましょう 。
プロンプト例:
以下の関数のユニットテストを書いてください:
- 正常系のテスト
- 異常系のテスト(null入力、空配列など)
- 境界値のテスト
AIはテストを書くのも得意です。機能と一緒にテストを生成させましょう。
テストファーストのアプローチ
さらに効果的なのは、テストファースト のアプローチです。
手順:
- まずテストを書く(AIに書かせる)
- テストが失敗することを確認
- 機能を実装(AIに書かせる)
- テストが通ることを確認
このアプローチには複数のメリットがあります。
メリット:
- 仕様が明確になる
- テスト漏れがない
- リグレッションに即座に気づける
- AIへの指示が具体的になる
最低限のテストカバレッジ
すべてをテストする必要はありません。最低限のテストカバレッジ を目指しましょう。
優先度の高いテスト:
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高 | 認証・認可 | セキュリティに直結 |
| 高 | 決済処理 | 金銭に直結 |
| 高 | データ保存・更新 | データ損失に直結 |
| 中 | バリデーション | 不正入力の防止 |
| 中 | ビジネスロジック | 正確性の担保 |
| 低 | UI表示 | 視覚的に確認可能 |
すべてを100%カバーする必要はありませんが、重要な部分は必ずテスト しましょう。
テストの種類
テストにはいくつかの種類があります。
ユニットテスト:
- 個別の関数をテスト
- 最も書きやすい
- 最も高速
統合テスト:
- 複数のコンポーネントをテスト
- APIエンドポイントのテスト
- データベースとの連携テスト
E2Eテスト:
- ユーザー操作をシミュレート
- 実際のブラウザでテスト
- 最も現実に近い
vibe codingでは、最低限 ユニットテスト は書きましょう。
CIでの自動実行
テストは 自動で実行 されるべきです。
GitHub Actions の例:
name: Test
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
- run: npm install
- run: npm test
これにより、変更をプッシュするたびにテストが実行されます。テストが失敗すれば、マージを止められます。
「テストがないコードは、壊れていないことを証明できない」
ソフトウェア工学の格言があります。
「テストがないコードは、壊れていないことを証明できない」
「動いた」という確認は、その瞬間の、そのケースで 動いたことしか証明しません。
テストがあれば、継続的に 動いていることを証明できます。
この事例から学ぶべき教訓
「テスト省略」から学ぶべきことは以下の通りです。
-
「動いた」はテストの代替にならない
- その瞬間、そのケースでしか証明できない
-
リグレッションは頻発する
- テストなしでは気づけない
-
AIにテストを書かせる
- 時間がないなら、テストもAIに
-
テストファーストを検討
- 仕様が明確になる
-
CIで自動実行
- 人間が忘れてもシステムが実行
まとめ:重要ポイントの振り返り
- 「動いたからテスト不要」は 致命的な誤り
- テストなしでは リグレッション に気づけない
- AIにテストを書かせる ことで時間を節約
- テストファースト で仕様を明確に
- CIで自動実行 、人間が忘れてもシステムが実行
- 教訓:テストがないコードは、壊れていないことを証明できない