GitHub Actions による CI で Autify E2Eテスト！ a-know/actions-autify-light の宣伝をします

この記事は Autify アドベントカレンダー2021の6日目のためのブログエントリです。Autify の中の人（Autify のカスタマーサクセスエンジニアをしています）よりお届けしています。

qiita.com

僕が Autify に入社したときのお土産（？）がわりだった、自作 GitHub Actions の a-know/actions-autify-light。README はある程度ちゃんと書いてはいるものの、それっきりだったりするので、改めてここで「それがどんなものか」について宣伝 紹介させてください！

github.com

どんなことをする action なのか

これについては、以下の通りです。

1. 指定された Autify テストプランを起動します。
2. 1.で起動したテストプランの実行を待ちます。
3. テストプランの実行結果に応じた exit code を返します。

シンプル。

GitHub Actions による CI に、「既存の Autify テストプランで指定したテストシナリオ（画面遷移やボタン等のクリック、テキスト内容の検証、etc.）が、今回の Pull Request で壊れてしまっていないか？」の検証を組み込むことができるようになります。

利用イメージ

上記の action を実際に組み込んでみているもの（練習用 Rails プロジェクト）がありますので、まずはこれを見てもらうと、イメージしやすいかと思います。

• mainブランチ "以外" に push したときに動くワークフロー用の YAML
  • 以下の順番でジョブを実行しています。
    1. コードの checkout など
    2. unit test の実行
    3. staging 環境を想定した Heroku project に deploy（ heroku push ）
    4. staging 環境（3. の deploy が行われた環境）に対して Autify テストプランを実行
• mainブランチに push したとき（基本的には Pull Request がマージされたとき）に動くワークフロー用の YAML
  • 以下の順番でジョブを実行しています。
    1. コードの checkout など
    2. unit test の実行
    3. staging 環境（この Pull Request がマージされる直前の内容が deploy されている（はず）の環境）に対して、Autify テストプランを実行
    4. production 環境を想定した Heroku project に deploy（ heroku push ）

上記からもわかるように、CIで実行するテストシナリオ・テストプランはあらかじめ Autify 側で作成しておく必要があります。

また、「その Pull Request により既存のテストシナリオの操作内容・フローが変わってしまうような場合」には、以下のいずれかの対応をしていくことになると思います。

• 「Pull Request による変更内容に合わせて、事前にテストシナリオの内容を更新しておく」対応
  1. 手元の環境（localhost など）を使って、テストシナリオを修正（再レコーディングなど）しておく
  2. 変更内容を Pull Request として push 。Autify でのテストが pass しているかどうかを CI status で確認する。
• 「後追いでテストシナリオの内容を更新を実施する」対応
  1. 変更内容を Pull Request として push 。staging環境のデプロイまでは行われるが、その後の Autify でのテストが失敗することを確認する。（失敗しなかったら、何かがオカシイ）
  2. staging環境にデプロイされたものを使って、テストシナリオを修正（再レコーディングなど）する。
  3. CIを再キックする。CI が pass することを確認する。

いずれの場合でも、Pull Request 内で Autify テストシナリオの更新履歴のリンクを示すなどして、「テストシナリオに対してどのような変更を加えたか（加える必要があるか）」についてもレビュー対象とできると、美しそうです。

利用方法

ワークフロー用の YAML のサンプルについては上記の通りなのですが、別途、環境変数などで以下の情報を渡してあげる必要があります。

• Autify プロジェクトID
  • ご利用の Autify プロジェクトIDです。
  • Autify にログインしたあとのURLが https://app.autify.com/projects/1/ だったとき、プロジェクトIDは 1 です。
• Autify テストプランID
  • CI で起動したいテストプランのIDです。
  • 対象のテストプランをブラウザで開いたときのURLが https://app.autify.com/projects/1/test_plans/3 である場合、テストプランIDは 3 です。
• Autify パーソナルアクセストークン
  • a-know/actions-autify-light では、内部的に Autify Web API を呼び出しています。そのため、パーソナルアクセストークンが必要になります。
  • 個人設定画面で発行することができます。この発行方法については公式のヘルプページを参照してください。

GitHub Actions での環境変数について、すこしだけ補足を。YAML で指定している各ジョブに environment っていう項目↓があると思うんですけど、

environment:
  name: staging

ここで指定した環境に対する環境変数の設定は、その GitHub リポジトリの Settings から行えます。

注意点とか

以下、ちょっとした注意点とか今後に向けての抱負を書いておきます。

• Autify テストプランの実行完了まで、定期的に結果をポーリングして待機します。
  • この待機中も、GitHub Actions の実行時間を消費することになります。
  • また、テストの所要時間によってはタイムアウト（当記事執筆時点では6時間がMAXのようです？）に対する考慮も必要かもしれません。
• ここで紹介した例は、「常に同じ staging 環境を利用する場合」の例です
  • 「Pull Request ごとに動的に検証環境を生成する」ような場合（Heroku だと Review Apps？ のようなものですかね？）には、現在の a-know/actions-autify-light は対応できていません
  • Autify としては対応しています（こちらの記事を参照してください）ので、やればできます。
    • がんばります or Pull Request お待ちしております！

以上です！Autifyでは、僕と一緒にこんなかんじのあれこれに取り組んでくれる仲間を募集しています！

autify.com