ClaudeExpo2025/12/15 17:00

Expo now supports Maestro Cloud testing in your CI workflow

要点だけを先に読めるように短く再構成したセクションです。

元記事

Quick Digest

要約

要点だけを先に読めるように短く再構成したセクションです。

claudejamodel: claude-sonnet-4-20250514

ExpoのCI/CDワークフローでMaestro Cloudテストがサポート開始

Key Points

  • EASワークフローでMaestro Cloudテストが統合サポート
  • GitHub ActionsとEASの複雑な連携コードが不要に
  • 並列実行による大規模テストの高速化を実現

Summary

ExpoがEASワークフローにMaestro Cloud統合を追加し、ビルドプロセスと同じワークフロー内でモバイルアプリのテストが実行可能になりました。従来のGitHub ActionsとEASの複雑な連携が不要となり、シンプルな設定でスケーラブルなテストが実現できます。

Key Points

  • 統合の簡素化: GitHub ActionsとEASの複雑な連携コードが不要
  • ワークフロー統一: ビルドとテストを同一のEASワークフロー内で実行
  • 並列実行: Maestro Cloudによる高速な並列テスト実行
  • 設定方法:
    • eas.jsonにMaestro Cloud統合用のワークフロー設定を追加
    • MAESTRO_CLOUD_API_KEY環境変数でAPI認証
    • .maestroディレクトリにテストフローを配置
  • コスト考慮: 既存のMaestro統合(無料)とMaestro Cloud(有料)の選択が可能
  • スケーラビリティ: 大規模テストスイートでの実行時間短縮効果が顕著

Full Translation

翻訳

原文の流れを保ったまま読める翻訳セクションです。

claudejamodel: claude-sonnet-4-20250514

ExpoがCIワークフローでMaestro Cloudテストをサポート開始

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: ['*'] # すべてのプルリクエストでE2Eテストワークフローを実行
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は、最大の信頼性のために各実行前に同じように準備されたデバイスでの並列実行を提供します。結果を収集し、トレンドを表面化するためのダッシュボードがあります - すべて非常にエンタープライズ的です(それが単語だとすれば)。

試してみて、どう思うか教えてください!