【Codecov】ターゲットを絞ってカバレッジを見た話
こんにちは!atama plusのigawyです。
atama plusでは、Codecov というカバレッジ測定ツールを導入して、コードカバレッジの測定と活用を進めています。
皆さんは測定したカバレッジをどのように活用していますか?
本記事ではターゲットを絞ってコードカバレッジを確認した話を紹介します。
Codecovを使ったカバレッジ収集
atama plusでは、Codecovを使って週に1回テストカバレッジを測定しています。
具体的には、github actionsでテスト実行〜カバレッジ収集〜Codecovへのアップロードを実施しています。
現在のコードは、よく変更するコード、しばらく変更していないコード、検証用のコード(検証結果によっては削除する可能性があるコード)、が混在しています。
atama plusでは、コード全体のカバレッジの目標値を設定して達成を目指すのではなく(目標値達成が目的化してしまうのを防ぐため)、必要な箇所に必要なテストが書かれていることを重視しています。
現在はアプリやライブラリのテストごとにFlagをつけ、アプリやライブラリごとにカバレッジの推移を測定し、大きな変化があったら個別にみていき対策を検討する方針をとっています。
今回はそれだけじゃもったいないということで、重要なコードの品質がどうなっているか確認してみました。
重要なコードとは?
Codecovはファイルごとにカバレッジを確認できますが、全ファイルのカバレッジを確認するのは効率的ではありません。
そこで、今回は利用頻度に着目しました。
具体的には、よく利用されるAPI=テストが書かれて品質が担保されているべき重要なコード、という仮説に基づき、Datadogを使って利用頻度の高いAPIを特定しました。
Datadogで調べてみたところ、利用率Top30のAPIが全体の50%以上を占めていることがわかったため、まずはTop30のAPIを調査対象にしました。
カバレッジ確認
確認対象が決まったので、次はカバレッジ確認です。Codecovを使いながら、各APIのカバレッジを確認していきました。
その結果、今回対象とした箇所についてはカバレッジの低いAPIはほぼないことがわかりました。
カバレッジの低いAPIが全くないわけではなかったですが(40%台が数件)、至急テストを追加した方が良いと判断するレベルのものはなかったので、非常に安心感が得られました。
以上のことから、Datadogなどを活用して調査対象を絞り込み、カバレッジを確認していくアプローチは有効であることがわかりました。
今回の確認については初めての試みでしたが、1-2時間程度で確認ができたため、効率的に確認できたと考えています。
おわりに
Codecovで収集したカバレッジの活用方法として、主要なコードにターゲットを絞って品質を確認した取り組みについて書きました。
今回の取り組みとは別に、直近mergeしたPRのカバレッジ推移を見て、カバレッジが下がっている箇所について理由を特定する取り組みも進めています。
また、カバレッジが下がる理由にも複数あるため(テストを書く時間がなかった、書きにくいコードだった、テスト観点が抜けていた、など)、原因ごとに対策を考えるアプローチも進めています。
コードカバレッジのみを目標にしてはいけないという記事はよく見かけますが、じゃあどう使ったら良いの?と悩む組織は多いのではないかと思います。
カバレッジの活用方法の一つとして参考にしていただけたら幸いです!
最後に、現在 atama plus では多くの職種で採用を行なっております。
新しいサービスも立ち上がっているので、一緒に盛り上げてくれる方、ぜひお話ししましょう!
Discussion