弊社ではオンラインコミュニティプラットフォームをコミュニティオーナー、エンドユーザーの皆様に安心してコミュニティをご利用、運営していただくためにテストカバレッジ向上を行っています。そのためにエンジニアチームとして取り組んでいることについて書いていきます。
これまで
OSIROというプロダクトは最初にリリースをしてから9年経過したプロダクトになります。
これまでの間に、コミュニティごとにRailsアプリケーションを作ったり、事情があってRailsでMySQLやPostgreSQLではなくSQL Serverを使っていたりしました。[1]
そんな事もあって、サービス開始から数年はまともにテストが書ける状況ではなかったかなと思っています。
テストカバレッジは60%くらいだった
特にマルチテナント化を行って、1つのRailsアプリケーションをデプロイすれば良くなったということもあったり、当時はRailsのアップデートも滞っていた[2]ことから、ある程度ユニットテストやE2Eテストを追加していくことを目標にして書いていきました。
これが2019年くらいのことですが、この時点でテストカバレッジは60%台になり、その数値を維持しています。
このときは決済系を中心にした部分はしっかりテストが行われるなど、全くテストがなかったということではありませんでした。ModelSpecは70%台でしたが、Controllerは50%を切っている状況で、明確にControllerのSpecが不足していることがわかりました。
主要OSSのテストカバレッジ
Railsの主要テストカバレッジを掲載しておきます。
もちろんこの数値が最重要視されているわけではないですが、まぁ80%以上にはしておこうねという暗黙的な雰囲気を感じます。
| プロジェクト名 | カバレッジ |
|---|---|
| mastdon | 85% |
| forem(dev.to) | 81% |
| Gitlab | 98% |
企業などのテストカバレッジ
いくつかの企業様のテストカバレッジに向けての記事を掲載しましたが、
ここでも80%前後が基準になってることが多そうです。
そんなこんなで目標設定
もちろんテストカバレッジが持つ数値自体持つ意味についてはいろいろな議論や意見があります。
しかし蔑ろにしすぎるのも良くないので、今年のゴールラインを下記として設定しました。
| ゴール | カバレッジ |
|---|---|
| Excelent | 90% - |
| Good | 85 - 90% |
| Be Must | 80% - 85% |
Excelentのゴールについてはタイミーさんの事例で、
テストカバレッジが90％以上で、Railsのアップデートについては自動テストで動作確認を担保して問題ないという判断があり、この方針にまで弊社としても持っていくことができれば最高のゴールだと思い設定しました。
とはいえ、スタートアップ企業として小規模なチームで開発のスピード感やサーバーサイド以外のことも色々やりたいとなるとExcelentの達成設定についてはちょっとやりすぎだったかもしれません。85%程度は今年中に持っていければよいのかなーと思っています。
テストカバレッジ向上させる理由
これまでRSpecを使ったユニットテストを書いていなかったわけではないですが、
ユニットテストを書いていない箇所を中心に不具合を発生させてしまい、ご迷惑をおかけしてしまうことが多かったため、この施策を決断しました。
テストがかけない、書きづらい理由は外部サービスを利用していることや、納期が厳しい時期があったなど様々ですが、RSpecでのテストがないことで不具合に気付けなかったり、デグレが発生してしまったりということがテストが網羅されていないことが理由でありました。
日々対応しながらも、毎週カバレッジ向上のタスクをアサインしていく
発起人である私も含め専業のメンバーは特にいません。
比率はことなれど、何かしらのタスクやPJTとの兼任となっています。
機能改善や不具合の修正を行う中で必要なテストが無いということであればそれらの追加も合わせてお願いしているようにしています。
並行してデットコードや利用していないWebAPIエンドポイントの削減などを行ってテストカバレッジやカバレッジに関わらない部分でのテストコードの追加であったり品質向上を図っています。
しかしそれだけでは足りなかったり、機能改善や修正の必要がない機能に対するテストコードがいつまで立っても増えません。なので、毎週のリリースMTGでは、機能改善や不具合の修正と同様に、機能の重要度を定義し、優先度の高いファイルやエンドポイントからテストカバレッジ向上のタスクをアサインしています。
毎週の雑振り返り
毎週リリースのためのアサインを中心としたMTGをプロダクトチームでしているのですが、
その中でどのくらいテストカバレッジが向上したのか？というのを実感してもらうためにも数値を共有するようにしています。
また、私のSlackの名前に現在のカバレッジ網羅率を入れておくことでざっくり自分たちがどのくらいの網羅率なのかを日々知ってもらえるように工夫をしたりしています。
4月での実績
テストカバレッジ向上以外にも内部品質向上のタスクをいくつかやってたり、
その他不具合の修正や機能改善を行っていますが、今のところ両立しながら実装できています。
4月からこの施策を開始し、まず1%ずつの向上を目指して、6月の終わりまでに75%にすることを達成目標として立てていますが、4月下旬の時点では68.7%「^３」なので、今のところは順調と言えそうです。
今後の課題
ふりかえりだったりをしている中で、フィードバックが集まりました。
- 優先しなければ行けないタスクがある場合はどうするのか？
- 個人のカバレッジが向上への貢献が見えづらい
- やはりDailyで確認できるようになっているとよい。
- PRごとにチェックできると良い。
Dailyでのチェックについてはこれまでカバレッジの計測をWeeklyだったものをDailyに変更して状況を細かく確認できるようにしました。
最終的にはPR毎にチェックできるようにしたり、Merge水準に達しない場合は、Mergeできないようにするなどの対応ができればと思っています。
まとめ
今回は弊社でテストカバレッジ向上に向けてやっていることを紹介しました。
このテストカバレッジ向上については4月開始で6月の終わりに一区切りするので、その際に結果がどうだったかを振り返る記事を書こうと思います。
テストカバレッジ向上のために行っている関連プロジェクトなどもあるのでこちらについても今後紹介ができればと思っています。
Discussion