💎

RailsプロジェクトのControllerカバレッジを半年かけて0%から85%に向上させた話

ペライチ Tech blog2022/09/02に公開

はじめに

こんにちは。
株式会社ペライチのソフトウェアエンジニアの松元です。

所属は予約チームで、主にサーバーサイドのエンジニアとして予約機能の機能追加や改修を日々行なっています。

この記事は予約機能のカバレッジを上げるために、約半年間取り組んできたことのまとめた記事になります。
どなたかの参考になれば幸いです。

前提

簡単に予約機能についての概要をまとめると、
バックエンドにRuby on Rails、フロントエンドにはNuxt.jsといった構成になっています。
リリースされたのは2019年12月でかれこれ3年弱運用されている、ペライチの中では中堅の機能です。

予約機能の課題

まだまだ成長中のプロダクトのため多くの課題を抱えているのですが、その中の一つにカバレッジの低さがありました。
全体のカバレッジは50%弱で、特にControllerに関してはテストが1行も書かれていませんでした。。。

新しい機能をリリースしたり細かい改善を繰り返したりと、度重なる改修によって思わぬところでバグが出るリスクは十分に考えられます。
また、現在オフショアの方々にRailsのバージョンアッププロジェクトを進行していただいています。
十分なテストをした上でリリースしますが、それでも不具合がでるリスクは否めません。

これらの問題を少しでも解消すべく、Controllerのカバレッジを85%に向上させることを目標としました。

※一応補足すると、全体のコードにおいてControllers配下のコードは約1/3を占めています。Controllerのカバレッジが上がれば必然的にプロダクト全体のカバレッジも向上できることを織り込んでの目標設定です。

取り組んだこと

目標を決めたらあとはひたすらテストを書いていくだけですが、取り組むにあたって特に以下の点を考慮しました。

目標までの細かな見積もりを立てる

当たり前ですが、テストの実装だけに注力するわけにはいかず、プロダクトロードマップにのっとった通常開発をこなしながらカバレッジの改善をしていかなければなりません。
そのため、事前にZenhubでリリースレポートを作成し細かく実装issueを切りつつ、スプリント毎にバーンダウンチャートを確認して都度見積もりを修正しながら進めました。

▼リリースレポート

スプリントゴールの中にカバレッジ改善のタスクを入れる

テストの実装はどちらかといえば「守り」の開発です。
「通常の開発が忙しくてなかなか進まない」といった状況は容易に想像できました。
そのため、僕一人が自由研究のように黙々と実装するというよりかは、スプリントゴールの中に入れてきちんと進捗を確認しながら実装していきました。

※補足:ペライチでは1スプリントを2週間としたスクラム開発をしています。

その他にもRSpecによるRailsテスト入門を事前に読んだり、過度なDRYは避けて実装するように工夫したり、色々と考慮した点はあるのですが、この記事では割愛します。

振り返り

約半年間カバレッジの改善に取り組んだ結果、設定した目標通りControllerのカバレッジが85%を超えました!

Before😖

After😀


またそれに伴って、全体のカバレッジも 45% => 86% に向上しました!!



Before😖

After😀

もちろん僕一人で全部やり切ったというわけではなく、他のエンジニアにレビューをしてもらったり、上長との1on1で一緒に進捗を確認してもらったり、チームの方々のサポートにはとても感謝しています🙏

一つ微妙だった点を挙げるとすると、既存のコードが既に存在するため通すためのテストになりがちだったことです。致し方ない部分ではありますが、今後新たにテストを書く際はこうならないように開発フローを模索していきたいです。

今後の課題・取り組み

今回半ば突貫工事のような形ではありましたが、当初立てた目標までカバレッジを向上させることができました。ただし、プロダクトの開発は恒久的に続いていきます。

「機能が増えるとともにカバレッジが段々下がっていく」という状態になっては元も子もないので、今の状態が最大瞬間風速にならないよう、維持し続けることが大事だと考えています。
カバレッジの目標値については、こちらの記事で以下のように説明されているため、これ以上あげる必要はないかなと思っています。

カバレッジは テストの完了条件とせずに努力目標とし 、クリティカルなコードではない限り、 カバレッジ(C0 / C1)の目標値は85%程度に設定すべきでしょう。

機能リリース時にテストも合わせて書いていくことはもちろんですが、例えばトライアル的にTDDを導入してみてそこで得たナレッジを社内に展開したり、今同じチームのサーバーサイドエンジニアの方がSwaggerの導入を進めているので、Swaggerを活用した開発フローを模索したり、既存のフローに囚われずにプロダクト価値の向上を見据えた開発体験の向上を目指していければと思っています。

採用情報

現在エンジニア募集しています!

▼ 採用ページ

https://recruit.peraichi.co.jp/

▼ 選考をご希望の方はこちら(募集職種一覧)

https://hrmos.co/pages/peraichi/jobs?category=1629135637016141824&utm_source=techblog&utm_medium=referral&utm_campaign=article-01gbw160thw7m07x9rxy0p9hjc

▼ まずはカジュアル面談をご希望の方はこちら

https://hrmos.co/pages/peraichi/jobs/0000029?utm_source=techblog&utm_medium=referral&utm_campaign=article-01gbw160thw7m07x9rxy0p9hjc

募集中の職種についてご興味がある方は、お気軽にお申し込みください(CTO がお会いします)

ペライチ

「テクノロジーをすべての人が使える世界に」を掲げるNoCodeサービス"ペライチ"を開発する、株式会社ペライチのメンバーのテックブログになります! エンジニアを募集していますので、下記リンクからカジュアル面談を気軽に応募してください☺️

Discussion

ログインするとコメントできます