はじめに
多くの方が、E2Eテストと聞くとフロントの画面のテストを思いつくと思いますが、今回は、バックエンドのE2Eテストについてやってこと、調べたこと、導入してみての結果を書いていこうと思います。
よろしければ、最後までお読みください！
そして、いいね❤️もよろしくお願いいたします！
対象読者
- 急にAPIのE2Eテストのタスクが降ってきた方
- バックエンドエンジニア
- Scenarigoに興味ある方
TL;DR
- APIテストに scenarigo オススメ
- aws sigv4を突破するのにproxyという選択もある
以上
今回導入するシステム
- とある業務DX系SaaS
雑な構成と今回のテスト範囲は以下の通り
よくある、っていうか個人開発でも使われるような The Serverless な構成
テスト範囲は、クライアントからAPIGateway → ECS → RDSの環境で期待するAPIの振る舞いを確認したい
やったこと
- 技術選定
- テスト設計
- 実装
ツール選定
制限事項
- 導入対象のシステムが NodeJs である
- コストはかけたくない
- AWS APIGatewayを使用しており、AWSSigV4署名が必須
- リクエスト元のIPを制限するミドルウェアやAPIKey認証がある
以下のツールを候補に挙げた
- Scenarigo
- StepCI
- runn
- newman
各ツールの紹介
基本的に、検討したツールはオープンソースです。
- Scenarigo
- StepCI
- runn
- newman
メリット・デメリット
| ツール | メリット | デメリット | 不採用理由 |
|---|---|---|---|
| Scenarigo | ・シンプルなyamlで書ける | ・NodeJsのプロジェクトなのでGo製のツールは学習コストが高い | - |
| StepCI | ・OpenAPISpecからシナリオを自動生成できる | ・レスポンスにnullがあるとエラーになる |
OpenAPIspecのexampleがそのまま使用できないため自動生成の恩恵がない |
| runn | ・シナリオからDBに接続してデータを作成したりできる | ・プラグインを書くとがっつりGoのテストになってしまう | NodeJsのプロジェクトなのでGoががっつり出てくるのは学習コストが高い |
| newman | ・PostmanのコレクションをCLIで使用できる | コレクションって有料プランでないと制限あったような・・・ | 無料枠で使用したかったので、今回は見送り。今度使う機会があれば調べて使っても良いかも・・・ |
上記にようなメリット・デメリットから、今回は、scenarigo で行くという選択をしました。
採用理由
- シンプルなyamlでテストを書ける
- Goを書く部分が最小限になる
- 日付とか可変でどうしようないところ期待値を
{ $ != "" }や{ $ > 0 }のように空文字でなけれなOKとかcountが0以上ならOKとか簡単に対応できた
また、今回、調べて出てきたが検討から除外したツール
- Karate
- シナリオがyamlでなく、独自記法であんまり好きなれなかった（個人的に）
- K6
- 負荷テストツール選定もちょうど同タイミングで、行っていたので一緒にしようかと考えたが、負荷テスト、E2Eテストはしっかり分けたかったため除外している
次に、以下では、実際にテスト自動化をどのように進めていったかを少しだけ抜粋して書いてみる
テスト設計
- リグレッションテストがメイン
- 200系をテストする
- 前提として、ロジックのテストはCIのユニットテストがある
- E2Eとして確認したいのはAWSの環境上のミスがないか、壊れていないかである
- 実際の業務と同じ方法でDEV環境にテストデータを作成する
APIの振る舞いが変わっていないことをテストしたい！！！
シナリオ作成
- APIは、全107本！！！
- レスポンスも膨大！！！
- APIGatewayには、AWS SigV4署名あり！！！
〜（心の声）〜
うわっ！量多すぎ！！！
認証も突破しないと！！！
面倒臭い！！！
〜〜〜〜〜〜〜〜
ここで、ちょっとだけscenarigoの使い方紹介
テストデータ作成
- 地道に画面からテストデータ作成
- シナリオの手作成はさすがきついので、APISpecから自動生成するツール作った
使い方はREADMEを参照していただけば！
バグ等のIssue受け付けております。
CIによる実行
- Github Actionsから実行！
- cronでのスケジューラ実行 ＆ 手動実行
- GitHub Actionsは慣れていたのでサクッとできた
この辺は、Scenarigo自体がCIフレンドリーなので、サクッとできましたし、
特段語ることはございません。
ただ、AWSSigV4署名は厄介でしたが最終的に以下のAWS公式のaws-sigv4-proxyのDockerコンテナを使用することで、
課題をクリアすることができました。
導入結果
導入して、１ヶ月も経っていない段階での記事となっております。
- DEV環境の自動での動作確認がステータスのみだった時から見る多少楽になった
- まだ、本格的には使われていないので 未知数 です
- これから、NodeJsやTypeORMのバージョンアップが 楽になるといいな
まとめ
- Scenarigoの使い方やGitHub Actionsからslack通知など知見が得られた
- ここまで確認したら安心が保証できる点を確保することが重要
- AWS SigV4署名めんどい
感想
もしかしなくても、事例は少ないです。グーグル先生には、フロントエンドのE2Eテストの記事なり、事例がたくさん出てきます。もっとこう、うちはこんなの使ったよ！こういう風に技術選定したよ！っていう共有が増えればいいなと思って、今回Qiitaに投稿してみました！
テスト自動化はやりすぎはよくないですが、デプロイ頻度の増加やリリースへの心理的障壁が下がるのであればどんどんやるべきと考えていますのでもっと事例欲しいですね！
参考
- Scenarigoを用いたAPIテストの取り組み
- 【書き起こし】Scenario-Based Integration Testing Platform for Microservices – 森 健太 -【Merpay Tech Fest 2021】
- QA Engineer3年生がグループ間を跨いで自動テストを推進していった話
さいごに
弊社では、エンジニア積極採用中です！
SES、請負、受託、Saleforce やりたい方はご興味を持っていただけたら幸いです。
ワクトでは、以下の Mission・Vision・Value を掲げております。
Mission : 「IT× ワクワク」で、社会の発展に貢献する
Vision : 大切な人に心から薦めたい会社であり続ける
Value :
One team for customers
熱意 × 人格 × 能力
まずやってみる
ワクトでは、もう一つ重要なものとして「 マインドマップ 」というものがあります。
個人的にですが、こちらに共感していただけた方はワクトに合うかなと思っております。
また、本記事の内容は個人の考えであり、会社を代表するものではございません。