最初に
STORES 予約 の開発をしているTak-Iwamotoです。
STORES 予約 ではmablを使用して、少しずつE2Eテストを導入し始めています。
この記事ではmablをどのように使用しているのか、利用する上でのtipsなどを書かせていただきます。
mablとは
mablはブラウザの操作をレコーディングすることでE2Eテストを作成できるサービスです。
cypressなどはコードでテストを実装する分、実装コストがかかってしまいますが、mablだとブラウザで動作確認するのと同じ要領でテストを実施できます。
STORES 予約 ではユーザーさまにとって影響が大きい予約画面や月謝・回数券の購入などの決済関連を中心に、正常系のみmablでテストを作成しています。
テストの作成方法
説明する必要がないくらいかんたんにテストを作成できますが、作成方法を説明します。
mablのデスクトップアプリをインストール
テストの作成にはmabl desktop appが必要なのでこれをインストールします。
mabl CLIをインストールして認証する。
テスト作成のためにmabl CLIをインストールします。 ドキュメント
テストをCLIから作成するために以下のコマンドで認証処理を行います。
mabl auth login
テストを作成する
以下のコマンドを実行してテストを作成するためのレコーディングを開始します。
mabl tests create http://localhost:8000/e2e-test-merchant sample-test
mabl tests createにテストを実行するurlとテスト名を渡します。
今回はローカルの開発環境に対してテストを実行します。
実際に実行している様子は以下のgif画像のとおりです。
ブラウザでデバッグするのと同じ要領でテストを作成できます。
CIへの組み込み
GitHub ActionsのCI環境でmablのテストをheadlessモードで実行しています。
mablはローカル環境に対してもテストを実行できるため、開発環境で使用しているdocker環境をCIに立ち上げて、そのlocalhostに対してmablのテストを実行しています。
具体的なGitHub Actionsのyamlは以下のとおりです。
on: push: jobs: run_mabl_test: runs-on: ubuntu-latest name: mabl test steps: - name: checkout rsv-frontend uses: actions/checkout@v2 - name: clone rsv-docker uses: actions/checkout@v2 with: repository: heyinc/rsv-docker path: rsv-docker token: ${{ secrets.GITHUB_ACCESS_TOKEN }} - name: clone rsv-api uses: actions/checkout@v2 with: repository: heyinc/rsv-api path: rsv-api token: ${{ secrets.GITHUB_ACCESS_TOKEN }} - name: setup Node uses: actions/setup-node@v2 with: node-version: ${{ env.NODE_VERSION }} cache: 'yarn' - name: install yarn run: npm i -g yarn@1.22.5 - name: yarn install run: yarn install --frozen-lockfile - name: Run applications by docker-compose up working-directory: ./rsv-docker run: | # 開発環境のdockerを立ち上げる docker-compose up -d rsv-api rsv-frontend - name: setup DB working-directory: ./rsv-docker run: | # E2E用のテストデータのセットアップ docker-compose run rsv-api bundle install docker-compose run rsv-api bundle exec ./bin/rails db:migrate:reset docker-compose run rsv-api bundle exec ./bin/rails db:seed docker-compose run rsv-api bundle exec ./bin/rails r db/seeds/e2e/e2e_test_data.rb - name: setup mabl cli env: MABL_CLI_API_KEY: ${{ secrets.MABL_CLI_API_KEY }} run: | yarn global add @mablhq/mabl-cli mabl auth activate-key $MABL_CLI_API_KEY # mablのテストを実行 - name: run mabl test uses: nick-fields/retry@v2 with: timeout_minutes: 25 max_attempts: 3 shell: bash command: mabl tests run --from-plan-id TEST_PLAN_ID --url http://localhost:8000/e2e-test-merchant --headless
実行していることとしては以下のとおりです。
- 必要なリポジトリのコードをCI環境にcloneする。今回だと、フロントエンド、API、dockerのリポジトリをcloneしています。
- docker-compose upで開発環境と同じ環境のアプリケーションを起動し、必要なデータをセットアップ。
- mabl CLIからテストを実行している。E2Eテストは壊れやすいことが多いので、何回かリトライして実行してます。
以下がテストを実行しているコマンドです。
プランが複数のテストをバンドルしたもので、CIで実行するテストをプランとしてまとめています。
mabl tests run --from-plan-id TEST_PLAN_ID --url http://localhost:8000/e2e-test-merchant --headless
利用する際のtips
XPathによる要素の指定
例えば、予約枠のカレンダーUIのテストを行う場合、1度E2Eテストを実施するとクリックした日時は予約済みとなりクリックできなくなるため2回目のテスト実行で失敗します。
こういった動的に要素が変化する画面では、data属性を付与し、XPathによって指定することで要素をクリックしています。
画面表示をassertする
ただ、レコーディングした操作を実行してテストするのみだと、期待される画面やレスポンスになっているのかわかりません。
assertのステップを使用して期待される画面や文言になっているのかなどチェックしています。
またi18n対応しているサービスでは、mablの実行環境で英語の文言でテストされる可能性があります。
この場合、テスト実行の際には英語のi18nにしてから文言のassertなどを行うと正しく検証できます。
ランダムな値を入力する
例えば、新規ユーザー登録を含むテストケースを登録する際にダミーのメールアドレスを使用したいケースがあります。
mablではランダムな値を変数として生成でき、これを使用することでテスト用のダミーメールアドレスなどを生成できます。
その他ベストプラクティスなどは公式ドキュメントをご参照ください。
最後に
STORES 予約 でどのようにmablを活用してE2Eテストを行なっているか書かせていただきました。
かんたんにテストを作成でき、CI環境にも組み込むことができるので非常に重宝しています。
ヘイ株式会社では絶賛採用活動中です。カジュアル面談も積極的に行っているのでご気軽にご応募ください!