ExpoがCIワークフローでMaestro Cloudテストをサポート開始
Product • Development • React Native • December 15, 2025 • 7分で読める
Dan Caseley ゲスト著者
EAS Workflows内でMaestro Cloudテストを実行し、ビルドと並行して実行できます。簡単なセットアップを学び、CIの接続コードを排除し、テストをより高速にスケールしましょう。
これはDan Caseleyによるゲスト投稿です - 彼はMaestroファン（およびスタッフメンバー）で、彼らが構築するものを日々積極的に使用しています。
...
私たちは本当に恐縮しています。ExpoはEASで実行できるワークフローにMaestro Cloud統合を追加しました。これは、ローカル環境では実現できないビルド容量と機能を持つだけでなく、同じワークフロー内で一流のモバイルテストツールを使用して構築したものをテストできることを意味します。
私はExpoでReact Nativeアプリを構築する多くの場所で働いてきました - 彼らのサービスを使用してビルドとリリースの苦痛を取り除いています。iOSコード署名を見ています😡。
当然、私は長い間Maestroユーザーでもありましたが、この2つを接続するのは困難でした。
統合前の苦労
これまで、私の通常のワークフローはGitHub Actionsでeas build --localを実行し、その後Maestro Cloud GitHub Actionを実行し、すべてEASトリガーと並行して実行するというものでした。確かに、テストはリリースするものと全く同じものをテストしているわけではありませんが、ほとんどのことについてはかなり近いものです。
そして、ローカル用のEAS設定をまとめる頭痛はそれほど悪くありませんでした。GitHub Actionは正しく設定するのに少し時間がかかり、ランナーが変更されるなどでメンテナンスが必要です。しかし、動作します。ほとんどの場合。
先週、EASでMaestro Cloud統合を試す機会があり、驚くほど簡単でした！すべての苦痛：消えました。
統合は、アプリとテストをMaestro Cloudにプッシュし、テスト結果を消費するためのラッパーです。以前にGitHub Actionを使用していた場合や、単にmaestro cloud <多くの引数>を実行していた場合と同じです。ただし、ビルドパイプラインで既に使用していたのと同じEASワークフローYAMLにあります。素晴らしい。
セットアップ方法
私がどのように行ったかを説明します...
ステップ1: アプリの準備
私はモバイルアプリ開発者ではないので、私のアプリケーションはnpx create-expo-app@latestを実行したときに得られるものに疑わしいほど似ています。快適に感じるために約6語を変更しました。
その後、npx eas-cli@latest initを実行してEASに接続し、これによりapp.jsonが更新され、これを一回限りのタスクにしました。
Maestroワークフローを開発する準備として、ローカルAndroidエミュレーターでアプリを実行したかったのです。npx expo run:android --variant releaseを使用しました（Maestroテストは常にリリースビルドでより代表的になるため）。これは初回で動作しました。
当然、慣例的な時間を待つ必要がありました - すべてのモバイル開発者が初回アプリビルド時に支払う税金です。お茶を飲み終えたとき、app.jsonにパッケージ名も追加されていることがわかりました。
ステップ2: スモークテストの作成
このシンプルな小さなアプリケーション用に最もシンプルな小さなテストを作成しました。
appId: com.danmaestro.maestroineas
---
- launchApp
- assertVisible:
text: 'Tab One'
- assertVisible:
text: 'Tab Two'
これにはmaestro studioの助けは必要ありませんでしたが、それほど自明でないもので取る手順と同じ手順に従って、とにかく使用しました。
ステップ3: EASの設定
EASドキュメントに従って、npx eas-cli@latest build:configureを実行して、EASでアプリに対して何をしたいかの設定を作成しました。これにより、プロジェクトのルートに合理的なデフォルト（'dev'はデバッグ可能、'production'ビルドはバージョン番号を自動インクリメント）を持つeas.jsonが生成されました。
既存のMaestro統合のドキュメントに従って、ワークフローで使用する追加のプロファイルをeas.jsonに追加しました（再び、代表的に保つため）。
最後に、同じドキュメントを適応して、Maestro Cloud統合用のワークフローを追加しました：
name: e2e-test-android
on:
pull_request:
branches: ['*']
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をここに残していることに気づくでしょう - これは秘密ではなく、保護する必要はありません。APIキーも含めていません。Expoは物事をシンプルに保つことに優れているので、APIキーは明示的に与えることも、プロジェクトのMAESTRO_CLOUD_API_KEY環境変数から取得することもできます。私は後者を選択しました - これが実際のプロジェクトであれば、このファイルを次に保守する人にとってAPIキーは不要でしょう。
パラメータの完全なリストは彼らのドキュメントで利用可能で、以前に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統合の代替案です。そこではMaestro CLIがEASインフラストラクチャでテストを実行し、ローカルテストを実行するときと同じ方法で行います。
どちらを選択しますか？
まず、Maestro Cloudは$0以上のコストがかかりますが、Maestro統合は既存のEASパッケージの一部です。私たち全員がそれを嫌っているとはいえ、それは考慮すべき点です。Maestro Cloudは趣味のプロジェクト向けではありません。成長の野心を持つ実際の本番アプリケーション向けです。
なぜMaestro Cloudを使用するのか？
ここにはスケールの問題もあると思います。適切なステップフローの総実行時間は2分かもしれません。5つのテストがある場合、10分待つことに満足するかもしれません。特に$0なら。
100のテストがあり、アプリの出荷を待っている場合、あまり満足しないかもしれません。上司もあまり満足せず、テスト結果をより早く得るために少し財布を開くかもしれません。
Maestro Cloudは、最大の信頼性のために各実行前に同じように準備されたデバイスでの並列実行を提供します。結果を収集し、トレンドを表面化するためのダッシュボードがあります - すべて非常にエンタープライズ的です（それが単語だとすれば）。
試してみて、どう思うか教えてください！