ExpoがCIワークフローでMaestro Cloudテストをサポートしました

Product • Development • React Native • 2025-12-15 • 7分読了

ゲスト寄稿：Dan Caseley

EAS Workflows内でMaestro Cloudのテストを実行できるようになりました。ビルドの横でそのままテストを走らせるシンプルなセットアップを紹介します。CIの接着コードをやめて、テストをより速くスケールさせましょう。

これはMaestroを普段から愛用している（かつスタッフでもある）Dan Caseleyによるゲスト投稿です。彼は日常的に彼らのツールを使ってアプリ開発をしています。

---

我々は少し照れています。ExpoはEASで実行できるワークフローにMaestro Cloudの統合を追加しました。これにより、ローカルでまかなえない規模・能力のビルドに加えて、同じワークフロー内で高品質なモバイルテストツールを使ってビルド済みアプリのテストも行えます。

私はこれまでいくつもの職場でReact Native＋Expoを使ってアプリを作り、ビルドとリリースの手間を省くサービスを利用してきました。iOSのコード署名の憎たらしさは皆さんご存知でしょう。自然な流れで私も長くMaestroを使ってきましたが、両者を繋ぐのはこれまで面倒でした。

統合前の苦労

これまでは通常、GitHub Actions上で eas build --local を走らせ、並列でMaestro CloudのGitHub Actionを実行し、EASのトリガーと並行して動かす、という手順にしていました。テストが完全にリリース対象と同じものを検証しているわけではありませんが、多くの場合は十分に近い結果が得られます。ローカル向けのEAS設定をまとめるのもそこまで大変ではありませんでした。

ただ、GitHub Actionはランナーの変更などに合わせて微調整やメンテナンスが必要で、そこそこ手間がかかります。しかし、とにかく動いていました。だいたいは。

先週EAS上のMaestro Cloud統合を試す機会がありましたが、驚くほど簡単でした。あの面倒が一切なくなります。

統合は、アプリとテストをMaestro Cloudへプッシュし、テスト結果を取得するラッパーです。以前のGitHub Actionや maestro cloud <many args here> を使っていたときと同じ流れですが、今回はビルドパイプラインで既に使っているEASワークフローYAMLの中に収まります。便利です。

セットアップ方法

私がやった手順を順に紹介します。

Step 1: アプリの準備

私はモバイルアプリ開発者ではないので、アプリは npx create-expo-app@latest を実行した直後とほとんど変わらないものでした。ほんの数語を直しただけです。

次に npx eas-cli@latest init を実行してEASに接続し、app.jsonが更新されてワンタイムの初期設定が完了しました。

ローカルのAndroidエミュレータでアプリを動かし、Maestroのワークフローを開発する準備をしました。リリースビルドの方が実際のテストに近くなるので、次のコマンドを使いました:

npx expo run:android --variant release

初回ビルドにはお約束の待ち時間が発生しますが、コーヒー／紅茶を飲んでいるうちに終わり、package nameがapp.jsonに追加されているのを確認しました。

Step 2: スモークテストを作る

単純なアプリに対して最小限のテストを作成しました。例：

appId: com.danmaestro.maestroineas
---
- launchApp
- assertVisible:
    text: 'Tab One'
- assertVisible:
    text: 'Tab Two'

このくらいのテストならMaestro Studioは不要ですが、今回は手順を揃えるためにStudioを使って同じ流れで作業しました。

Step 3: EASの設定

EASのドキュメントに従って次を実行し、EASにどう振る舞ってほしいかを設定しました:

npx eas-cli@latest build:configure

これでプロジェクトルートに eas.json が作られ、例えば dev はデバッグ可能、production はバージョンを自動インクリメントする、といった合理的なデフォルトが設定されました。

既存のMaestro統合のドキュメントに従い、ワークフローで使う追加のプロファイルを eas.json に追加しました（代表性を保つため）。そして同じドキュメントを参考にして、Maestro Cloud統合のワークフローを追加しました。例：

name: e2e-test-android
on:
  pull_request:
    branches: ['*'] # Run the E2E test workflow on every pull request.
jobs:
  build_android_for_e2e:
    type: build
    params:
      platform: android
      profile: e2e-test
  maestro_test:
    needs: [build_android_for_e2e]
    type: maestro-cloud
    params:
      build_id: $ { { needs.build_android_for_e2e.outputs.build_id } }
      flows: '.maestro/smoke.yaml'
      maestro_project_id: proj_01jy292wt8et3ayd00prxbjkwh

ここで注意してほしいのは、プロジェクトIDは公開情報で問題ないのでYAMLに置いてあります。APIキーは含めていません。Expoはシンプルさに優れていて、APIキーは明示的に渡すことも、プロジェクト内の MAESTRO_CLOUD_API_KEY 環境変数から拾うこともできます。私は後者にしています — 実際のプロジェクトであれば、このAPIキーを次にメンテナンスする人がわざわざファイルに書く必要はありません。

パラメータの一覧はMaestroのドキュメントにありますし、CLIやGitHub ActionsでMaestro Cloudを使ったことがある人ならほとんど馴染みのあるものばかりです。

代表的な設定にしているとはいえ、次の作業は手早く済ませました。PRを作ってワークフローをトリガーする代わりに、信頼して手動で起動しました:

npx eas-cli@latest workflow:run .eas/workflows/e2e-test-android.yaml

少し待つと、ビルドとテストが完了しました。出力は以前の maestro cloud コマンドのものと同じような形で表示され、そこからリンクを辿ってMaestro Cloud上で実行詳細を確認できます。

今日アプリを作るなら、私はこの方法でセットアップします。どのステップも難しくなく、リポジトリに残る設定も扱いやすいです。コードに集中でき、ビルドや配布のための呪文のような手順が減りました。素早く動いても、何も壊さない自信が持てます。

Maestro Cloud vs. 標準EAS統合：どちらを選ぶべきか

これは、既存のEAS内のMaestro統合（ローカルでテストするのと同じようにEASインフラ上でMaestro CLIを走らせる）に対する代替手段です。どちらを選ぶかは用途次第です。

まず現実的な点として、Maestro Cloudは無料ではありません。一方で標準のMaestro統合は既に持っているEASのパッケージの一部として使える可能性があります。趣味プロジェクトにはMaestro Cloudは必ずしも適していません。Maestro Cloudは成長を目指す本格的なプロダクションアプリ向けです。

なぜMaestro Cloudを使うのか？

スケール面での利点があります。まともなフローの合計実行時間が2分程度なら、5個のテストで合計10分待つのは許容できるかもしれません（しかも無料で）。しかしテストが100個になり、アプリを出荷しようとしている状況なら、結果を早く出したいはずです。上司の機嫌も良くないでしょうし、少しコストをかけてでも結果を早く得たい状況は十分にありえます。

Maestro Cloudは並列実行を提供し、各実行前にデバイスを同一の状態に準備することで信頼性を高めます。ダッシュボードで結果を収集しトレンドを可視化する機能もあり、いわゆるエンタープライズ向けの機能群が揃っています。

まずは試してみてフィードバックをください！