コードが変更された際に、コードやインタフェース単位での単体テスト(ユニットテスト)を漏れなく実行するだけでなく、利用者目線で「ちゃんと動作する」ことの検証までできているでしょうか？ 本ブログでは、mabl で作成した E2E テストセットを CircleCI で実行する方法をご紹介します。
はじめに
アプリケーションの開発において、単体テスト はコードが変更されてから、できるだけ時間を空けることなく実行することで、テスト結果が想定と異なっていたとしても、コードを開発した人の頭の中にロジックや変数などが鮮明に残っているうちに修正に取り掛かることができます。
リポジトリにコードがコミットされてから時間が経過してしまうと、「えっと、ここってなんでこうしたんだっけか…」と思い出すところから修正に取り掛かることになるからです。しばしばいわれることですが、「３日前の自分が書いたコードは他人が書いたコード」なのです。
一方で、単体テストにおいては検出されなくても、アプリケーションをユーザーと同じ状況で、同じように利用してみることで見つかる不具合というのも確かに存在します。
本ブログでは、そういった「ユーザーと同じ状況」でテストする、つまり、個々の機能ではなく、ユーザーの達成したいゴールが一連の操作の中で実現できているかどうかを確認するための End to End テスト(E2Eテスト、User Interfaceテスト、UIテスト、インテグレーションテストなどと呼ばれることもあります)を mabl というテスト自動化のソリューションを使って自動化し、CircleCI と連携してテスト実行する方法をご紹介いたします。
ガイドの目次
E2E テストの自動化
今回はテスト対象として、Node.js をつかって1ソースコードで記述した ToDo 管理アプリ NodeToDo をテスト対象として使用します(リポジトリはこちら)。
E2Eテストを実行する前に、CircleCI を使うことで、
- ビルド (依存関係のあるライブラリを npm install で取得) - build_web ジョブ
- テスト (今回は単体テストではなく、eslint を使ったチェック) - test_web ジョブ
- リリース (Dockerコンテナ化し、イメージを Amazon ECR に登録することで、AWS App Runner テスト環境に自動デプロイ - release_image ジョブ
を自動化し、自動デプロイした NodeToDo を mabl を使って実際にテストしていくことにします。
E2Eテストの実行には CircleCI を活用しましょう。
mabl と CircleCI との連携
CircleCI の自動化ワークフローは config.yml ファイル上で定義します。
- 本プロジェクトの config.yml ファイル
CircleCI にはアプリケーションやサービスとの連携を簡潔に定義・記述するための Orb と呼ばれる「部品化」「再利用」の仕組みを用意しています。これにより、重要ではあるけれども、定型的な記述を何度も繰り返し行わなくても良くなるわけです。
mabl との連携も、mabl/trigger-tests Orb を使うことで、(その名前が示している通り) mabl を使った自動テストを CircleCI のワークフローからトリガーすることが容易になります。
この trigger-tests orb が提供するコマンドのうち、実際にテストを実行するのが run-tests コマンドです。run-tests コマンドは、次に挙げるようにいくつかのパラメータを指定することができます(指定可能なパラメータはこれら以外にもあります)。
| パラメータ | 説明 |
|---|---|
| api-key | mabl の API キー。未指定時は環境変数 MABL_API_KEY の値が参照される。 |
| application-id | mabl を使ってテストを実行するアプリケーションの ID。 |
| environment-id | mabl を使ってテストを実行する際のテスト環境(environment)の ID。 |
これらのパラメータの値が mabl の画面上でどのように取得できるのかと合わせて、テストを作成していきましょう。
mabl を使ったテストの自動化
E2Eテストを自動化するにあたり、mabl のワークスペース、テスト環境、プラン、テストを順に説明していきます。
ワークスペース
mabl のワークスペースとは、後述する環境やプラン、テストを包含する一番大きな単位です。例えば、無料トライアルを始めると、このワークスペースが1つ、割り当てられます。
下に挙げた mabl の画面でも示しているように、左側でワークスペースを選択し、API タブを選択することで、mabl の API キーを作成したり、作成した API キーをコピーすることができます。
コピーした API キーは、CircleCI のプロジェクト設定(Project Settings)画面から環境変数(Environment Variables)を選び、MABL_API_KEY の値として設定しておきます。
テスト環境
mabl のテスト環境は、アプリケーション(Web アプリケーションであれば URL)やクレデンシャル、DataTable から構成されます。
今回は、特にログイン操作は必要ないのでクレデンシャルは設定せず、任意のアプリメーション名(ここでは nodetodo-mabl)、および NodeToDo アプリのデプロイ先の URL を指定しておきます。
プラン
mabl のプランとは、どのテスト環境(先ほど作成)、どのステージの中で、どのテスト(後述)を、いつ(トリガー)、どのブラウザで実行するのかを管理する単位です。
テスト
mabl のテストとは、Web アプリケーション上での操作や、その操作の結果、画面のどの部分でどういった操作を行うのか(値の入力やボタンの押下)、画面上はどのように表示されているのかをチェックする(アサート)といったステップを順に定義したものです。
右下にある作成ボタンを押すことで、指定された表示サイズでブラウザが表示され、ブラウザの右側に mabl トレーナーが表示されます。
あとはブラウザ上で操作を行ったり、アサートボタンを押した後、チェックすべき領域と期待する値のセットを設定するなどして、一連の操作を記録しながら、E2E テストの手順を半自動的に定義していくことができます。また、各ステップの順序の入れ替えや、チェックすべき値の変更・修正も容易に行うことができます。
テスト手順を登録したら、テスト実行ボタンを押すことで、ローカル環境上で一連の手順が自動実行、およびチェックされるのを目視で確認しながら実行することができます。また、ローカル環境上でではなく、mabl のクラウド側で実行することも可能です。
CircleCI からの E2E テスト呼び出し
再び mabl アプリケーション上で ワークスペース > API タブ を見てみましょう。
アプリケーションと環境(つまりテスト環境)を作成し、プランとテストも定義が完了しているので、これらを画面中ほどの「デプロイ時にテストを実行」上で、アプリケーション、環境、プランラベルを選択することで、mabl CLI のコマンド例が表示されます。
trigger-tests orb の説明をした際に、run-tests コマンドのパラメータをご紹介いたしましたが、その際に application-id と environment-id については何も説明していませんでしたが、このコマンド例を元に、パラメータの値を設定する、というのが答えになります。
パラメータの値を反映したジョブ run_mabl_tets の定義は次のようになります。
run_mabl_tests:
machine: true
steps:
- trigger-tests/run-tests:
application-id: naMfa4ho96G0Al0ccA8KcA-a
environment-id: Ba4jXgdJPoZdWrfPEzAFBw-e
- trigger-tests/parse-results
- store_test_results:
path: ./test-results
おわりに
アプリケーションやサービスに求められているのが、新たな機能をいかに多く羅列するかではなく、これまではできなかった、あるいは機能的にはできていたとしても、直感的な操作ではたどり着けなかったゴールへの道筋をわかりやすい形で提示するということであるとすれば、そういったユーザー体験をサポートするような開発がより一層求められ、合わせて E2E テストの継続的な実行がより重要となることでしょう。
本ブログが、ビルド、テスト、リリース、デプロイの自動化に加え、E2E テストの自動化の導入のきっかけとなれば幸いです。
