リグレッションテストツールを作成し社内で広めた話
こんにちは、みみぞうです。
ナビタイムジャパンで『システムや開発環境、チームの改善』を担当しています。
本記事では、私がOSSとして個人的に開発したリグレッションテストツールについて紹介します。このツールは社内の20プロジェクトで利用実績があり、毎月100万を超えるテストが実施されています。
何ができるツールなのか
2つの環境にデプロイされたAPIに対し、同じリクエストをして返却される結果の差分を調べることができます。デグレードが起こっていないかをチェックできることから、社内ではデグレチェックと呼ばれています。
デグレチェックはJumeauxとMiroirという2つのツールで構成されています。それぞれ紹介します。
Jumeaux
テストを実行するPython製のCLIツールです。『じゅもー』と読みます。
処理の途中にアドオンレイヤーがあり、自由に挙動をカスタマイズできるのが特徴です。
たとえば、以下のような設定ができます。
・レスポンスのjsonに含まれる .id の値は無視して比較する
・テストリクエストが特定のpathを含む場合のみ判定処理を変更する
・チェックの結果に応じてSlackへの通知メッセージを切り替える
以下のページで簡単なチュートリアルを用意しています。よろしければお試し下さい。
Miroir
Jumeauxで実行したテスト結果をGUIで確認するWebアプリです。TypeScriptとAngularを使っています。『みろわーる』と読みます。
Jumeauxが出力するjsonのレポートは人間に優しくありません。そのため、通常はMiroirを使ってテスト結果を確認します
以下は社内で実際に行ったテストの結果をMiroirで表示した画像です。
特定のテストリクエストをクリックすると詳細が表示されます。
Miroirでも、差分が問題ないプロパティを設定で無視することができます。
上の画像では .features[].properties.indoor プロパティが削除されている場合、『indoorフラグが削除されるのは問題ない』と設定しています。これにより、誰も把握していない新しい差分 のみに集中してチェックすることができます。
詳しい説明は以下のページをご覧下さい。
・結果で表示されるテーブルの項目 (Trial table)
・プロパティ無視などの設定 (Check YAML)
・差分の性質から全体を俯瞰する (Analytics)
Miroirのビルド/デプロイ方法はGitHubのREADMEをご覧下さい。
なお、記事内で紹介したイメージ画像はNAVITIME APIに対するデグレチェックの結果です。
ナビタイムジャパンでの利用シーン
社内では以下4つのシーンで主に利用されています。
❶ オンプレからクラウドへの移行
❷ システムのリプレイス/大規模リファクタリング
❸ サービスデプロイ前の最終確認
❹ 期待値の定義が困難なテスト
❶～❸のケースは 対応前後での期待値が同一である であり、本ツールの利用シーンにマッチしています。❶のようなインフラストラクチャーが変わるケースでは予期せぬ影響でデグレードが起こる可能性も高く、非常に高い効果があります。
❹について、具体例として経路検索機能があります。経路検索は時間や状況によって最適解が変わるため、テストの難易度が非常に高いです。期待値ではなく差分ベースで確認可能な本システムを使えば、このような期待値を一意に定めることが困難なケースであっても影響範囲を正確に把握できます。
また、テストに使用する確認リクエストは実際にサービスで利用されているリクエストパターンを元に用意しています。生きたリクエストを使うことで、既に利用されているサービスが停止するリスクを最小限に抑えるよう務めております。
まとめ
社内で利用実績のあるリグレッションテストツール、JumeauxとMiroirについてご紹介しました。
今後も『システムや開発環境、チームの改善』について関係あるお話を発信させていただければと思います。