📕

開発チームにおけるバックエンドテストのガイドライン策定の軌跡をふりかえる

2023/10/05に公開

はじめに

株式会社マイベストでバックエンドエンジニアをしています、井上周(@isaka1022)です。
マイベストの開発組織において、2023年度の後半にかけて、バックエンドのテストの書き方の方針、ガイドラインの策定のプロジェクトを担当しました。

そもそもどのようにテストの書き方を決めるのか、また、ガイドラインとして機能させるためにエンジニア全員で共通認識を持てるものに仕上げるか、など考えることが多かったのですが、なんとか形にすることができたので今回はどのようにガイドラインを策定したか、その背景や経緯をお伝えできればと思います。

ガイドライン策定の背景

mybestのアーキテクチャには近年、Ruby on Railsに加えてNext.jsが導入されました。
それに伴い、バックエンドのテスト環境に大きな変化がありました。

それまでもテストの書き方のルールが決まっていなかったこともそうですが、RailsのViewも含めた開発であればバックエンドエンジニアだけでも動作確認できたこともあり、テストが書かれている箇所にムラがある状況でした。

Next.js導入によりこれまで以上にフロントエンドとバックエンドが分離されたことで、バックエンドの動作を確実に担保する必要性が高まりました。

さらに、チーム人数の拡大もあり、新しいメンバーが増えることで、テストの書き方やそのルールにバラつきが生じることが懸念されました。このような状況下で、統一されたテストのルールやガイドラインを策定する必要が出てきたのです。

ガイドライン策定の課題

ガイドラインやルールを策定する際の最大の課題は、その解釈の一貫性でした。
特にテストに関するルールは、開発者の解釈や背景知識、経験によって大きく異なる場合があるため、誰が見ても同じ解釈ができる明確なガイドラインの策定が求められました。もしも解釈にばらつきがあると、ルールに従ってテストの不足をコードレビューで指摘した際に不要な議論が生まれたり、そもそも指摘できないルールにしてしまうと、形骸化そてしまう可能性もあったからです。

そこで、誰が見ても同じ解釈ができるテストの品質を示す指標として「カバレッジ」を採用することにしました。

https://service.shiftinc.jp/column/4547/

しかし、実際には全てのコードを高いカバレッジレベルでテストすることは、リソースや時間の制約上、現実的ではありませんでした。
このような状況で、どの部分をどの程度テストすべきか、どのようにテストの優先度をつけるかという問題が浮上しました。
このグラデーションを機械的、かつ公平に決定する方法が見当たらなかったのです。どの機能がビジネス上での重要度が高いのか、どの部分がシステムの安定性に寄与しているのかといった、多角的な視点からの評価が必要であり、これを一元的に定義することは困難でした。

解決策

このような課題を解決するための一つの答えとして、私たちはmybestにおける「システム重要度」という新しい指標を導入することにしました。この指標は、ビジネス上のドメインを踏まえてシステムの重要度を評価し、それに基づいてテストの優先度を決定するものです。

具体的な運用として、リファインメントの際にPdMとエンジニアが連携し、開発予定の機能や改修がどのドメインに関連するのかをすり合わせることで、開発するシステムの領域の重要度を明確にします。これにより、開発段階でのテストの範囲や深さを事前に明確にすることができるようになりました。
また、見積もりについても「テストをどこまで書くから〇〇くらい必要です」というコミュニケーションができるようになります。

例として、「決済」に関わる部分は、システム全体の中で非常に高い重要度を持つと考えられます。不具合があると、直接的な収益損失や顧客の信頼喪失を招く可能性があるからです。同様に、「クライアント関係」や「法律関連」など、特定のビジネス上のドメインも高い重要度を持つと考えられます。
このような観点から既存ののシステムがどのようなドメインで分割できるかを考え、優先度付けを行いました。

ここで決まった「システム重要度」をコードレビューの過程でレビュワーが確認し、適切なカバレッジでテストが書かれているかという視点でレビューを行います。これにより、ガイドラインに従ったテストが書かれているかをチェックし、品質の確保を徹底します。

このような流れでガイドラインおよび運用を策定することで、開発者全員が共通の認識を持ってテストを行うための土台が整備されました。

完成したバックエンドテストガイドライン

作成したガイドラインは下記のようなものになります。
一旦こちらのガイドラインで運用しつつ、なにか問題があったり、対応できないケースが合った際にはフィードバックをもらいつつ、適宜更新しています。

結果

この新しいガイドラインと「システム重要度」の導入により、マイベストではバックエンドの質と開発効率を担保していくことになりました。
今後もこのガイドラインをベースに、継続的な改善と最適化を進めていきたいと考えています。

参考サイトなど

ガイドライン策定に当たり参考にさせていただいたサイトなどです。

メルカリ社など、他社のガイドラインも参考にさせていただきました。

https://engineering.mercari.com/blog/entry/20220418-e406d51f15/

テストについての考え方について参考にさせていただきました。

https://www.amazon.co.jp//dp/4839981728

https://speakerdeck.com/carta_engineering/geek-sai-2022-autumn-yanyan-backend-study?slide=38

「プライベートメソッドのガイドラインどうするか?」という論点が出てきたのでいくつか参考にさせていただきました。

https://t-wada.hatenablog.jp/entry/should-we-test-private-methods

https://anond.hatelabo.jp/20201220182440

Discussion