※Claude Codeを使用して記事を作成しています。
シリーズ：Claude Codeを使ったAndroidアプリ開発 失敗談
- #1〜7：指示・ライブラリ・コードまわりの失敗
- #8：テストを書かずにClaude Code任せにしたら品質が崩壊した話 ← 今回
はじめに
Claude Codeで実装スピードが上がると、「テストは後でいいか」という気持ちになりがちです。
私もそうでした。
その結果、機能追加のたびにどこかが壊れるアプリになっていきました。
やらかしたこと
メモアプリの開発を進めるうちに機能が増えてきました。
ある日、リマインダー機能を追加した後にアプリを起動すると、それまで動いていたメモの削除機能が突然クラッシュするようになりました。
原因を調べると、リマインダー実装時にFirestoreのデータ構造を少し変えていました。
その変更が削除処理と競合していたのです。
テストがあれば、リマインダーを実装した時点で削除機能のテストが失敗してすぐ気づけました。
テストがなかったため、実際に動かすまで気づきませんでした。
テストなし開発の問題
| 状況 | テストあり | テストなし |
|---|---|---|
| 機能追加後 | 既存機能が壊れていないか自動確認 | 手動で全画面を確認するしかない |
| バグ発見のタイミング | 実装直後 | ユーザー報告 or 偶然 |
| 修正後の確認 | 自動で全ケースを再確認 | また手動で確認 |
Claude Codeにテストを書いてもらう
テストを書くのが面倒という人も、Claude Codeに書いてもらえます。
メモの削除機能のユニットテストを書いてください。
テストすべきケース：
・メモが正常に削除されること
・存在しないIDを削除しようとしたときのエラーハンドリング
・削除後に一覧からメモが消えていること
MockKを使ったテストでお願いします。最低限のテスト戦略
全部テストするのは難しくても、壊れると致命的な処理だけテストするだけでも大きく変わります。
以下の処理のユニットテストを追加してください。
「このテストが落ちたら絶対にリリースしない」という重要な処理です。
・ユーザー認証のロジック
・メモの保存・削除処理
・リマインダーの日時計算ロジック新機能追加時のお作法
この失敗以降、新機能を追加する際は必ずこの順番にしました。
1. 既存のテストを全部実行して全部通ることを確認
2. 新機能を実装
3. 新機能のテストを追加
4. もう一度全テストを実行して全部通ることを確認
5. 完成Claude Codeへの指示にも「テスト付きで」を追加するだけで、実装とテストをセットで作ってもらえます。
リマインダー機能を実装してください。
実装と合わせて、ユニットテストも書いてください。まとめ
Claude Codeで実装スピードが上がるほど、テストの重要性が増します。
速く作れるからこそ、壊れたときの影響範囲も大きくなるからです。
「テストは後で」ではなく「テストは実装とセットで」を習慣にしましょう。
次回：【Claude Code 失敗談 #9】Claude Codeに設計を丸投げしたらアーキテクチャがグチャグチャになった話
