【エンジニアブログ】開発効率向上のためのrunn活用

GMOメイクショップ コアグループ エンジニアの越川です。 直近の開発でAPIの開発がありました。シナリオテストを導入したかったので、今回の案件で導入してみました。 導入したruunが便利だったので、記事にさせていただきました。

• 1. 動機・モチベーション
• 2. 構成
• 3. runnについて
• 4. 実装
• 5. GithubActionsに埋め込み
• 6. 実行結果
• 7. まとめ

1. 動機・モチベーション

シナリオテストに関して、前々から、導入検討していました。 弊社の開発環境ではCI/CDが導入されているため、Githubのブランチへのマージを契機に Actionsが自動でECSのコンテナにデプロイしています。 開発者はマージだけで済むので、便利ではあるのですが、 開発環境での動作確認は開発者に任せられているので、動作確認の強度に個人差があり、 ごく稀に、デプロイを失敗しているのを見逃されるケースや 他チームのサイレント修正によってトラブルが発生するケースがありましたので、 E2Eテストを実施して、基本的なシナリオはデプロイ後も問題なく動いていることは担保したいと考えていました。

2. 構成

構成イメージ

イメージの通りですが、ECSのデプロイを待ち合わせてからシナリオテストする必要があります。

3. runnについて

github.com

golangのテストヘルパーとして組み込めたり、様々な利点・特徴があるツールだと思いますが、 今回の案件では、以下の簡易さをメリットに感じて、採用しました。

• DBの初期データセットアップ
• APIのチェーン

4. 実装

DBの初期データを調整したあとにsample1APIを叩いたレスポンスを使用して、sample2APIをコールするサンプルになります。

sample2にsample1のレスポンスを値を渡して実行しております。 簡単にAPIチェーンが書けて素敵です。

5. GithubActionsに埋め込み

これだけなので非常に簡単です。

6. 実行結果

少し抜粋していますが、正常時と異常時のレスポンスは以下のような形になります。

正常

異常

7. まとめ

入れてみての感想ですが、予想以上に役に立ってます。 開発中の案件だったので、簡単なコーディングミスや、認識齟齬でデプロイ後にテストが落ちたの検知したり、 他チームの変更に巻き込まれたりに気づけて、少し安心感を持って開発ができるようになりました。

◆　他のBlogはこちらから⇒　https://tech.makeshop.co.jp/　◆