食べチョク開発者ブログ

食べチョクエンジニアによるプロダクト開発ブログ

テストのカバレッジをコツコツ上げた話

こんにちは、endo と kawabata です。 今回はプロダクトチーム内の自動テスト改善チームでコツコツカバレッジを上げた取り組みと振り返りのお話をしたいと思います。 ここでテストのカバレッジを上げているのは、RSpec でのお話になります。 テストのカバレッジを上げていこうというお話は、こちらの食べチョクの自動テスト改善活動 〜これまでとこれから〜のお話からきています。

ゴールを設定せずに活動するのは良くないので、10 月末までにカバレッジを 80%まで上げるということを目標に設定しました。 80%まで上がれば広範囲をカバーできているだろうというざっくりとした見立てです。 今回の取り組みでは、大きく分けて以下の 3 点を実施しました。

  • どのテストを追加するか決める
  • コツコツテストを追加する
  • 不要なコードを削除する

どのテストを追加するか決める

テストのカバレッジを上げていこう!というのはいいのですが、闇雲にやっても改善幅が見えません。 そこで、改善幅を見つけるためにRSpec 実行時のレポート情報をクエリで可視化するで現状の状態を可視化しました。

その結果、どこから着手するかが見えてきました。

RSpecのグループ毎のカバレッジ

  • Controller / Mailer / Jobs のカバレッジが全体よりも低い
  • 3 つのグループの中で Controller は実際のエンドユーザー側へのコンテンツの表示に関わる割合が多い

ということで、Controller のカバレッジを改善しようという話になりました。

では、どのファイルからやるのか?というところも闇雲にやっても改善が見えづらいです。 カバレッジが低いものから着手しようということで、カバレッジが低いものを抽出しました。 これでテストを追加する対象が明確になりました。

Controllerのカバレッジが50%以下のファイル

コツコツテストを追加する

目標達成までに対応が必要なファイル数を算出し、目標達成までの日にちから逆算して毎週各メンバーに割り当てました。 平均すると 1 人毎週 1 ファイル追加するペースで進めば目標達成となる計算です。 テストを追加する対象が決まりマイルストーンも設定できたので、あとはコツコツと追加していくのみです。

しかし、ここからが大変でした。 最初のうちは順調に進んでいたのですが、途中からペースが鈍化し思うように進まない期間もありました。 各メンバーの業務状況により、テストを追加するための時間が確保できないというのが大きな要因でした。 これに関しては優先順位の兼ね合いで仕方ない部分があり、解決策がないので「先週出来なかったので今週は 2 つ追加しよう」みたいな感じで進めました。

不要なコードを削除する

テストの追加と並行して不要な機能やデッドコードを削除する活動も進めました。 使われていない処理のテストを追加しても無駄になりますし、テストがない不要はコードを削除すればカバレッジも上がるだろうという想定でした。 その結果、想定通りカバレッジ向上に効果的でした!

不要コード削除後の50%未満Controller数

不要コード削除後のカバレッジ

最終結果

コツコツテストを追加したり不要なコードを削除した結果、全体カバレッジが 80%を超えました!

最終全体カバレッジ

Controller 単体でも 80%を超えました!

最終Controllerカバレッジ

目標も達成したので、自動テスト改善チームは解散となります。

振り返り

今回の活動を振り返ってみて良かった点と課題が見えてきました。

良かったこと

グラフによるカバレッジの可視化

日々テストを追加してもカバレッジの増加はごくわずかです。 成果が見えづらいとモチベーション維持も難しくなります。 カバレッジをグラフ化していたことで日々右肩上がりに増えていくのを確認でき、 活動のモチベーション維持にも役立っていたと思います。

設定した目標を達成できた

業務状況により進捗が少ない時期もありましたが、自然消滅せず目標を達成できたことも成果の 1 つだと思っています。 あまり進捗しない状況でも継続することの大切さを改めて実感しました。

課題

安定した作業時間の確保

上でも書きましたが、各メンバーの業務状況によりテストを追加する時間を確保できないという状況が発生しました。 今回の取り組みだけのことではなく、こういった改善活動では起こり得ることです。 これに関しては良い解決方法が見つかっていませんが、 定期的にミーティングを開催して進捗状況の共有を行なっていたのは、良かったと思っています。 (個人的にミーティングのたび『頑張って進めないと!』と感じ、モチベーション維持に役立っていました)

おわりに

80%を超えたカバレッジですが、日によっては 80%を下回っています。 日々システムが進化していてコードは増え続けていますが、それに対応したテストが不足している場合があるということですね。 カバレッジが高いから良いというものではありませんが、必要なテストが不足していることは問題です。 自動テスト改善チームは解散となりますが、プロダクトチーム全体としてテストを書くということを意識していきます。

目標達成後のある日の全体カバレッジ