はじめに
こんにちはテックリードのかどたみです。 突然ですが、マイクロサービスでの開発を始めてから3年が過ぎ去りました。。。時の流れは早いですね。。。
既存のサービスの運用を行った後、そこにある課題をできる限り再現させないように新たなコードベースを構築してきました。 その中でも個人としてはテストに課題感を持ち以前こんなポエムも書きましたが、ポエムを書いただけで振り返ってこなかったのでここで振り返ってみたいと思います。
この記事はエモーションテック Advent Calendar 2024の2日目の記事です。
効果の実感
しっかりテストを書いてきて良かったことは、やはり仕様の変更時に安心ができるということが一番だと思えます。 マイクロサービスを導入し、新たに作っているプロダクトは仮説検証の段階にあります。そのため一度リリースしたものでも機能の追加や仕様の変更がとても多く、その度に自動テストに助けられています。 その中でも特に取り組んで良かったものを紹介します。
データストアとの結合テストの自動化
弊社ではPostgreSQLやRedisを始め、BigQueryもデータストアとして活用をしています。 データストアとのデータの読み書きをモックしてしまう方法もあると思いますが、弊社では実際にデータを読み書きしてテストを行っています。 PostgreSQLやRedisはCI上でDockerを立ち上げて実行しています。シードデータのようなものは基本的には用いず、テストケースごとに一意制約にかからないように識別子をすべてランダムで生成し、対象データの生成やテストの実行を行っています。 実際に読み書きを行うことで各データストアや接続するためのライブラリのバージョンアップにおいて安心感が得られます。
BigQueryはデータの書き込みと読み込みをするサービスが分かれているので、読み込み側ではテストデータの生成を事前に行うことでテストを実現しています。 具体的にはテストに用いたいデータをCSVで用意しておき、BigQueryが提供しているデータの読み込み機能を用いてテーブル作成からデータの生成までを行うスクリプトをGitHub Actionsで動かしています。 これによってパフォーマンス改善などでSQLを修正した際、動作の正しさを保証することができるようになり大変重宝しています。
時間を購入する方針
あまりテストに限った内容ではないのですが、マネージャーが定めたチームの方針として良いと思ったことを紹介します。 弊社はGitHub Actionsを用いてCI/CDの構築を行っており、自動テストがすべて成功しないとマージできない様になっています。そこで問題になってくるのはやはり実行時間です。
テストのみならず、Dockerでデータストアを立ち上げたり、Rustなどのコンパイル言語をビルドしたりと、機能やコード量が増えれば増えるだけCIの時間は伸びていきます。並列化をしたり、キャッシュを利用することによってある程度解決をすることもできますが、手間がかかる上、効果が薄い場合もあります。せっかくプルリクエストを作成してもすぐにレビュー依頼を出せず、他の作業をしていて脳内メモリから揮発して放置されるなんてことがあったらもったいないです。
なので弊社ではCIの実行環境にはお金を注ぎ込んで実行ができる限り高速に終わるようにしています。GitHub Actionsでは実行できるRunnerのスペックを変えることができるので、実行時間がストレスになった場合にはマネージャーに許可を取ってより大きなRunnerに変更することが可能です。
反省と課題
全体的に効果は実感しつつも、いくつか反省や課題があるので紹介します。
生成されるSQLのテスト
前章で記載した通りデータストアとの結合テストを行っていますが、BigQueryでのテストの仕組みができる前は最低限の担保としてクエリ生成のコードにおいてSQLが文字列として正しいかどうかを判定するテストを書いていました。 実際、既存のSQLが壊れないように条件を追加した場合の処理を記載する際などはありがたかったのですが、パフォーマンス改善や生成されるクエリの多くのパターンに変更が入る仕様変更では修正範囲が大きくなり足かせになる場合もありました。 実際のデータを用いたテストが行われている場合はSQLを文字列としてテストする必要性はあまりないなと感じていて、個人的には廃止していきたいと考えています。
ほかにも、Interceptorのテストなど動作確認すれば必ず動作担保ができているものはわざわざ自動テストを書かなくても良いかもしれません。書かれていないテストはカバレッジで確認できても、ありすぎるテストはなかなか検知できないので難しいところですね。実行時間やQAチームの有無によって最適な自動テストは模索していきたいです。
フレームワークの新たな仕組みを利用したコードに対するテスト
ローンチした時点での機能を使い続けているのであれば、テストコードもあまり変更がなく既存のものを参考にしていればいいですが、フレームワークによっては更新頻度が高く、より書き心地やパフォーマンスが良い機能が出ますよね。 弊社で利用しているAngularは特にここ数年での変化が激しく、マイクロサービス開発を始めてからも様々な設計パターンを考え試しています。最近だとv16から導入されたSignalsを用いた開発が行われています。
しかし、このSignalsのテスト導入において課題を感じています。導入時にstableでない機能の利用にもチャレンジした事によってテストの型化ができず、カバレッジが低下しました。Signalsに依存しないロジックなどはテストが書かれているのですが、依存している部分はテストしたい状態の準備や検証方法などをあまり確認しないまま開発期間に入り、QAチームの検証を頼りに自動テストが手薄なままリリースされている部分があります。
機能としては便利なものであり、新しいものを導入するチャレンジは続けることが大事ですが、今後新しい機能を導入する際はテスト方法の確立は導入前にやっておくことを心がけたいと思います。
これら以外にもマイクロサービス間のテストがQAチームによる手動テストのみであったり、カバレッジを上げる文化が不十分な部分もありますが、これからも改善していきたいと思います。
おわりに
いかがだったでしょうか？課題はいくつかありますが、やはりテストは書くことによる恩恵が大きいです。私が入社した当初は既存のプロダクトのテスト改善から着手をし、ある程度形にしてきました。その経験を活かしながら新たなプロダクトを作れていること、それに賛同が得られるチームであることはとてもありがたいことです。テストに関するこのマインドはキープしつつ新たな課題には真摯に向き合ってより良いテストライフを送っていきたいと思います。
エモーションテックでは顧客体験、従業員体験の改善をサポートし、世の中の体験を変えるプロダクトを開発しています。プロダクトに興味のある方、テストを通して保守しやすいプロダクトを作ることに興味がある方、ぜひ採用ページからご応募をお願いいたします。
