RSpec のテストカバレッジ率向上の取り組み
こんにちは。アルダグラムでエンジニアしている前山です。
弊社では、今年の4月から7月にかけて、技術戦略として、バックエンド側のテストを整備していく取り組みをおこないました。
技術スタックは、バックエンドは Rails で GraphQL を採用しています。テストフレームワークは RSpec 使用しています。
今回の取り組みで、RSpec のカバレッジ率が約 70% から 80% 以上超えることができたので、どのようにテストを整備していったのか紹介できればと思います。
1. 整備したいテストの棚卸し
最初に行ったのは、どのテストが整備していくかを明確にするための「整備したいテストの棚卸し」です。SimpleCov の Report の結果を元に、以下のテストを整備すると効果がより出ると判断しました。
- GraphQL API
- Model
今回は特に、GraphQL リゾルバと GraphQL ミューテーションに焦点を当て、整備されていないファイルを全て洗い出しました。
(ちなみにこの棚卸しは、弊社の @DtanaD にしていただきました)
※画像にある対象ファイルはダミーです
2. 月に 1回、テストをみんなで書きまくる
次に、月に1回、テストをみんなで書きまくる日を設定・スケジュールを確保し、その名の通り、テストを1日中書きます。
(弊社では、この日のことを RSpec 整備デー と呼んでいました)
具体的な進め方としては、以下のようになります。
- 棚卸ししたスプレッドシートから、対応できそうなものを見つける
- 着手する前に「担当」欄で自分を選択する
- 「対応状況」を「対応中」に変更する
- 「ブランチ名」でブランチを切って RSpec を書く
- LGTM を貰ったらマージし、「対応状況」を「対応済み」にする
当日の参加者は 8人程で、1回の開催で、カバレッジ率が約 1 ~ 2.5% 程、テストを整備していきました。
※上記の画像は RSpec 整備デーが終わったときの成果報告の様子
3. 不要なコードをクリーニング (削除)
不要なコードが存在すると、それ自体はアプリケーションに影響を与えないかもしれませんが、いいこともありません。不要なコードがあると、開発スピードの低下、テスト作業の増加、さらには予期せぬバグの原因となる可能性があります。なので、不要なコードは削除した方がいいと思います。
普段の開発で不要なコードを見つけたり、SimpleCov のレポートも活用しました。
SimpleCov のレポートでカバレッジが 0% と表示されているファイルは、以下の2つの可能性が考えられます。
- そのファイルのテストが全く書かれていない
- そのファイルのコードが使用されていない
2 の場合は、不要なコードになるので、削除していきました。
削除していくときに、削除対象ファイルが多いときは、棚卸しをして、本当に削除して問題ないかダブルチェックをして、削除していきました。
※画像にある対象ファイルはダミーです
このように RSpec (テスト) 整備デー とは、別に、不要なコードを見つけたら削除するように推進しました。
結果・まとめ
これらの取り組みを4ヶ月続けた結果、RSpec のカバレッジ率が 80 %以上になりました!(現在は約 83%)
特に 月に1回、みんなで一気にテストを整備していく施策がテスト整備推進の起爆剤になりました。各チームあらゆるタスクを持っていて、忙しい状況でもあったので、開催頻度としても月に 1回 くらいがちょうどよかったかなと振り返って思います。
またこういった取り組みをみんなで行うことで、バックエンド側のテストを書く文化もさらに根付けられたかなと思います。
今後は、テストの網羅率もそうですが、テストの品質もより上げていくための取り組みもできたらなと考えています。
もっとアルダグラムエンジニア組織を知りたい人、ぜひ下記の情報をチェックしてみてください!
株式会社アルダグラムのTech Blogです。 世界中のノンデスクワーク業界における現場の生産性アップを実現する現場DXサービス「KANNA」を開発しています。 採用情報はこちら herp.careers/v1/aldagram0508/
Discussion