レガシープロジェクトにテストコードを増やすために取り組んでいること
はじめに
現在、10年以上稼働しているRailsプロジェクトを担当しています。
APIのカバレッジは40%程度で、チームメンバーもテストのメリットを理解していない状態でした。コードの品質にも課題があります。
この環境でテストを増やすために取り組んでいることを共有します。
なぜやるのか
- コード品質を改善したいが、テストもなく仕様も複雑で手を出せない
- ドキュメントが残ってないものもあり、仕様がわからない
- 開発生産性を上げたい（人間もAIも）
コード変更の恐怖感をなくす・価値提供のスピードを上げるというのがねらいです‼️
現在やっていること
1. 現状を仕様化するテストを書く
10年物のコードは正しい仕様が不明な場合があります。そこで、現在の動作をそのまま正として記録する「仕様化テスト」を書いています。
例えば価格計算のロジックがなぜその金額になるのか不明でも、現在の計算結果をそのまま期待値にしてテストを書きます。
メリットは以下です：
- バグも含めて現状をそのまま仕様として記録できる
- 現状を正とするので比較的すぐにテストが書ける
2. controller, modelの統合テストを増やす
ControllerからModelまで通しでテストを書いています。
これにより、ControllerとModelの動作をまとめて保証しながら、責務移動などのリファクタリングも安全に行えるようになりました。（この方法はt_wadaさんに直々におすすめしていただきました！）
3. 振る舞いをテストする
実装の詳細ではなく「何をやっているか」をテストしています。
例えば「user.update(active: true)を呼ぶ」ではなく「管理者は無効なユーザーを有効化できる」というようなテストをしています。
メリットは以下です：
- 内部実装を完全に理解していなくてもテストが書ける
- テストケースが減って管理しやすい（内部の全パターンではなく振る舞いだけ）
- リファクタリングしてもテストが壊れにくい
何をテストケースにすればいいか迷いにくい
4. AIツールでテスト生成
Claude Codeなどを活用してテストの雛形を生成しています。最初のテストは自分が書いて、それをAIに参考にさせて作ってもらっています。生成されたテストをそのまま使うことは少ないですが、叩き台があることで作業が格段に早くなりました。
特に既存コードからテストケースを網羅的に生成させて、不要なものを削除していく方法が効果的でした。
5. 勉強会の実施
テストの勉強会を開催してメリットを実感してもらう取り組みも行っています。実際にテストがバグを防いだり生産性が向上する実感を持ってもらうことで、徐々に理解が広まってきています。
現状やっていないこと
カバレッジの向上を目標にしていない
カバレッジを上げることを目的にすると、質の低いテストが増えてしまうと思いました。（実装の詳細だったり、必要性が少ない部分のテストばかり増えたり）
カバレッジ自体は重要ですが、現時点ではそれを追うよりもまずテストを書くのを当たり前にするのが先だと思い、一旦値は気にしていません。
単体テストにこだわっていない
モックを多用した純粋な単体テストより、DB接続込みの統合テストを優先しています。
理想的ではないかもしれませんが、現実的に動作を保証できる方を選んでいます。
完璧なテストを求めていない
仕様が不明な箇所は現状追認でも良しとしています。
完璧を求めて手が止まるより、書ける分でも書くのが大事だと思っています。
まとめ
テストがあると、人間だけでなくAIもより働きやすくなると思うので、テストを書くのを当たり前にしていきたい🔥
Discussion