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