「機能追加の後」や「本番リリースの前」に、Autifyによるテストの実行を行うことで「それまで問題なく動作していた機能に問題が出ていないかどうか」を担保することは、Autifyの理想的な活用の仕方の一つです。

CI（Continuous Integration：継続的インテグレーション）やCD（Continuous Delivery：継続的デリバリー）のフローに、Autifyによるテスト実行を含めることで、それを自動化することができます。ですが、そうしたCI/CDフローにより自動的に生成される検証環境には、毎回異なるURLが発行されるというケースも少なくありません。

図1: 常に同じURLの環境へデプロイが行われる例

図2: 毎回異なるURLの環境へデプロイが行われる例

このページでは、こうしたケースに対応していただくためのベストプラクティスをご紹介します。

前提条件

この記事では、以下の2点については既に存在するものとしています。

CircleCI、Jenkins、GitHub Actions などの仕組みを活用して実現された、CI/CDのためのジョブフロー
- また、都度発行された検証環境のURLをジョブフロー内で把握することができるものとします。
特定のタイミングで自動的に実行させたいテストシナリオを指定したテストプラン

また、Autify には以下の4種類のAPIが存在しています（2021年10月現在）が、この中でも太字で表しているAPIがこの記事で使用するAPIです。

schedules
- テストプランの実行
scenarios
- テストシナリオの取得
results
- テスト結果の取得
url_replacements
- URL置換条件の操作

APIに関する詳細は API ドキュメントを参照してください。

パーソナルアクセストークンを発行する

上記のような自動化を実現するために、Autify Web API を活用します。

API を実行するためには、パーソナルアクセストークンが必要となりますので、これを予め発行しておきます。パーソナルアクセストークンは、サイドメニューの「設定」から「個人設定」を開き、その中の「新しいパーソナルアクセストークンを生成」から生成することができます。

Screen_Shot_2021-09-14_at_17.13.01.png

既存のジョブフローに、Autify Web API を呼び出すジョブを追加する

以下のような処理を行うジョブを追加します。

3-1. 対象テストプランの「URL置換条件」を追加する
3-2. 対象テストプランを実行する
3-3. 3-1. で追加した「URL置換条件」を削除する

以下に詳しく説明します。

対象テストプランの「URL置換条件」を追加する

「URL置換条件追加API」を用いて、対象のテストプランにURLの置換条件を追加します。

例えば、対象のテストプランに設定されているテストシナリオが https://example.com に対する操作をレコーディングしたもので、それをその時のジョブフローの実行時には https://1234567.example.com という検証環境が生成される場合、以下のようなAPIリクエストを発行することで、対象のテストプランに対して「URL置換条件」を追加することができます。

curl -X POST -H "Authorization: Bearer PERSONAL_ACCESS_TOKEN" https://app.autify.com/api/v1/test_plans/{test_plan_id}/url_replacements -H "Content-Type: application/json" -d '{"url_replacement": { "pattern_url":"https://example.com", "replacement_url": "https://1234567.example.com"}}'

PERSONAL_ACCESS_TOKEN は 1. で発行したものと、 {test_plan_id} は対象のテストプランのID（そのテストプランをWebコンソールで開いたときに、そのURLが https://app.autify.com/projects/1/test_plans/3 であれば、そのテストプランIDは 3 です。）と、それぞれ置き換えてください。

このAPIリクエストを発行することは、Webコンソール上で以下のように設定を追加することと同じです。

この機能については、こちらのドキュメントもご参照ください。

こうすることで、テストシナリオが https://example.com に対する操作をレコーディングしたものであっても、テスト実行時にはその実行先を自動的に https://1234567.example.com に置換した上でテストを実行します。

上記のAPIリクエストが正常に行えた場合、以下のようなレスポンスを得ることができます。

{"id":1111,"test_plan_id":12345,"pattern_url":"https://example.com","replacement_url":"https://1234567.example.com","created_at":"2021-09-15T01:23:45.678Z","updated_at":"2021-09-15T01:23:45.678Z"}

この情報のうち 1111 は、ひとつひとつの「URL置換条件」を識別するためのIDです。これは後ほど活用します。

対象テストプランを実行する

「テストプラン実行API」によりテストを実行します。例えば以下のようなAPIリクエストを発行することで、対象のテストプランのテスト実行を起動することができます。

curl -X POST -H "Authorization: Bearer PERSONAL_ACCESS_TOKEN" https://app.autify.com/api/v1/schedules/{test_plan_id}

PERSONAL_ACCESS_TOKEN や {test_plan_id} は、2-1. と同様に適切に置き換えてください。

「テストプラン実行API」へのリクエストが適切に発行できると、以下のようなレスポンスを得ることができます。

{"data":{"id":"999999","type":"test_plan_result","attributes":{"id":999999}}}

このレスポンスに含まれる id （ここでは例として 999999 としています）は、そのテストプランの実行結果を識別するためのIDです。ジョブフローを先に進めるためには、起動したテストプランの結果を取得する必要がありますので、このIDを元に、「テスト実行結果取得API」をリクエストします。例えば以下のような方法です。

curl -X GET -H "Authorization:Bearer PERSONAL_ACCESS_TOKEN" https://app.autify.com/api/v1/projects/{project_id}/results/{result_id}

PERSONAL_ACCESS_TOKEN については......もう大丈夫ですね？

{project_id} は、ご利用のAutifyプロジェクトのIDで置き換えます（Autifyにログインしたときに、そのURLが https://app.autify.com/projects/1 であれば、プロジェクトIDは 1 です）。{result_id} は、「テストプラン実行API」をリクエストした際のレスポンスの内容（上記の例だと 999999 ですね！）を指定します。

Autifyによるテストの実行が完了するまでには、多少時間を要します。テストの実行がいつ終わるかはテストによってまちまちですので、実際には「テスト実行結果取得API」を定期的に実行して、テストが完了したかどうかを確認する必要があります。

その仕組みを自作することは少々手間が掛かります。以下のサービスの場合についてはそのためのサンプルを用意していますので、ぜひ参考にしてください（順次拡充していく予定です！）。

3-1. で追加した「URL置換条件」を削除する

無事テスト実行を終えることができたら、今回のジョブフローの実行で動的に追加された「URL置換条件」を削除しておきましょう。（そうしないと、次にこのテストプランを実行したときに、再び https://1234567.example.com に対してテストが実行されてしまいます。）

以下のようなAPIリクエストを発行することで、2-1. で追加した「URL置換条件」を削除することができます。

curl -X DELETE -H "Authorization:Bearer PERSONAL_ACCESS_TOKEN" "https://app.autify.com/api/v1/test_plans/{test_plan_id}/url_replacements/{url_replacement_id}"

上記コマンドの中の文字列の置き換えは、もう皆さんも慣れたものだと思います。

唯一、 {url_replacement_id} は 2-1. で得た「URL置換条件」を識別するためのIDのことを指しています。ここでの例だと 1111 という数字で置き換えることになります。

このAPIリクエストが正常におこなえたら、今回追加した「URL置換条件」の削除も成功です。これですべてが元通りです。

以上、動的に生成される検証環境に対してテストを実行する際の自動化ベストプラクティスのご紹介でした。お疲れ様でした。こちらの内容を参考に、ぜひ良い Autify 体験を生み出していただけたらと思います！

参照記事