Maestro E2E

Q: Onde os arquivos de fluxo residem?

Convenção: .maestro/ na raiz do projeto (irmão do eas.json). Nomeie os fluxos por jornada (login.yml, checkout-guest.yml), não por número de sprint.

Q: Qual é o separador --- em fluxos YAML?

Linhas acima de --- são configurações (appId, name opcional, env). Linhas abaixo são a lista de comandos executados em ordem.

Q: Como o EAS sabe qual binário de aplicativo instalar?

O job maestro build_id referencia o artefato do job build no mesmo workflow. Compile com o perfil e2e-test para que a saída seja um .apk instalável ou .app de simulador.

Q: Como direciono um elemento com texto duplicado?

Adicione testID no React Native. Prefira id em vez de toques de coordenada - coordenadas quebram em diferentes tamanhos de tela.

Q: O Maestro pode preencher campos de texto seguro?

Sim - inputText funciona em campos seguros focados. Certifique-se de que o campo seja tocado primeiro. Teste em ambas as plataformas; o comportamento do teclado difere no simulador iOS.

Q: Como reutilizo uma sequência de login?

Mantenha sub-fluxos em .maestro/subflows/ e referencie com runFlow.

O Maestro controla seu aplicativo instalado em um simulador ou emulador com fluxos declarativos em YAML - toque, role, afirme texto visível - sem escrever código de harness de teste nativo. Combine-o com builds do EAS para que cada PR execute as mesmas jornadas que o CI executa localmente.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

# .maestro/login.yml
appId: com.yourcompany.yourapp
---
- launchApp
- tapOn: "Sign in"
- tapOn:
    id: "email-input"
- inputText: "alex@example.com"
- tapOn: "Continue"
- assertVisible: "Welcome back.*"

// eas.json (excerto)
{
  "build": {
    "e2e-test": {
      "withoutCredentials": true,
      "ios": { "simulator": true },
      "android": { "buildType": "apk" }
    }
  }
}

# .eas/workflows/e2e-test-android.yml
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
    params:
      build_id: ${{ needs.build_android_for_e2e.outputs.build_id }}
      flow_path: [".maestro/login.yml"]

Quando usar isso:

Jornadas críticas do usuário: login, checkout, onboarding, deep links de notificação push.
Fluxos que cruzam o chrome nativo - permissões do sistema operacional, barras de abas, teclados do sistema.
Portões de regressão antes da submissão para a loja (complementa Melhores Práticas de Teste).
Equipes que desejam que não desenvolvedores leiam e estendam cenários de teste em YAML.

Exemplo de Trabalho

Layout do projeto:

your-expo-app/
  .maestro/
    home.yml
    explore-collapsible.yml
  .eas/
    workflows/
      e2e-test-android.yml
      e2e-test-ios.yml
  eas.json
  app.json

// app.json (excerto - fonte da verdade do appId)
{
  "expo": {
    "name": "Tasks Demo",
    "slug": "tasks-demo",
    "ios": { "bundleIdentifier": "com.example.tasksdemo" },
    "android": { "package": "com.example.tasksdemo" }
  }
}

# .maestro/home.yml
appId: com.example.tasksdemo
---
- launchApp
- assertVisible: "Welcome!"
- tapOn: "Tasks.*"
- assertVisible: "No tasks yet"

# .maestro/explore-collapsible.yml
appId: com.example.tasksdemo
---
- launchApp
- tapOn: "Explore.*"
- tapOn: ".*File-based routing"
- assertVisible: "This app has two screens.*"
- scrollUntilVisible:
    element: "Learn more"
    direction: DOWN

// eas.json
{
  "build": {
    "e2e-test": {
      "withoutCredentials": true,
      "ios": {
        "simulator": true
      },
      "android": {
        "buildType": "apk"
      }
    }
  }
}

# .eas/workflows/e2e-test-android.yml
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
    params:
      build_id: ${{ needs.build_android_for_e2e.outputs.build_id }}
      flow_path:
        - ".maestro/home.yml"
        - ".maestro/explore-collapsible.yml"

# Execução local (após instalar o Maestro CLI e um build de depuração no emulador/simulador)
maestro test .maestro/home.yml
maestro test .maestro/
 
# Acionar EAS Workflow manualmente
npx eas-cli@latest workflow:run .eas/workflows/e2e-test-android.yml

O que isso demonstra:

appId corresponde a android.package / ios.bundleIdentifier de app.json.
Correspondências de Regex - Tasks.* e Explore.* toleram pequenas alterações de rótulo e diferenças de texto entre plataformas.
Perfil de build e2e-test - produz .apk (Android) e .app de simulador (iOS) sem credenciais de loja.
Job maestro do EAS - instala o artefato de build do build_id e executa os fluxos de flow_path.
Fluxos independentes - cada arquivo YAML é uma jornada; falhas identificam a tela quebrada.

Mergulho Profundo

Como Funciona

O Maestro CLI se conecta a um emulador/simulador em execução (ou dispositivo físico) e inicia o aplicativo por appId.
Cada fluxo é uma lista ordenada de comandos (launchApp, tapOn, inputText, assertVisible, scrollUntilVisible, …) executados contra a árvore de UI ao vivo.
O Maestro usa rótulos de acessibilidade e texto visível - adicione testID / accessibilityLabel no React Native quando a cópia sozinha for ambígua.
EAS Workflows type: build produz um binário instalável; type: maestro baixa esse binário para o runner e executa os fluxos - sem upload manual de artefatos.
Os fluxos são caixa-preta - eles não importam seu JS; mudar a implementação não quebra os testes se a UI visível para o usuário permanecer a mesma.

Comandos de Fluxo Comuns

Comando	Propósito
`launchApp`	Inicialização fria (ou retomada) do aplicativo em teste
`tapOn`	Tocar por texto, id ou regex (`"Sign in"`, `id: "submit-btn"`)
`inputText`	Digitar no campo focado
`assertVisible` / `assertNotVisible`	Falhar rapidamente se a cópia ou id estiverem faltando
`scrollUntilVisible`	Rolar até o elemento aparecer - listas e telas longas
`runFlow`	Compor sub-fluxos para etapas de login compartilhadas
`extendedWaitUntil`	Esperar pelo elemento com timeout - portões de carregamento assíncronos

Opções de Integração com CI

Abordagem	Prós	Contras
Job `maestro` do EAS Workflows	Integração nativa com Expo, build + teste vinculados	Requer assinatura do EAS e configuração de workflow
GitHub Actions + `maestro test`	Controle total dos runners	Você gerencia a inicialização do emulador, instalação do APK e cache
`maestro test` local antes do PR	Feedback mais rápido	Não imposto a menos que o CI também seja executado

O Expo documenta o caminho do EAS Workflows em Executar testes E2E no EAS Workflows com Maestro.

Controles para Testes Instáveis

# .maestro/checkout.yml
appId: com.example.tasksdemo
---
- launchApp
- extendedWaitUntil:
    visible: "Catalog"
    timeout: 15000
- tapOn:
    id: "product-card-1"
- assertVisible: "Add to cart"

Técnica	Quando
Regex (`Welcome.*`)	Pequenas diferenças de pontuação ou strings de plataforma
`extendedWaitUntil`	Telas carregadas pela rede, transição splash → home
`id:` / `testID`	Texto visível duplicado na tela
Fluxos curtos e focados	Isolar falha - evitar mega-fluxos de 40 etapas
`runFlow` para login uma vez	DRY sem mesclar asserções não relacionadas
Contas de teste estáveis / dados de semente	O estado do backend não deve depender da produção

Acompanhe a taxa de instabilidade ao longo do tempo com Insights do Maestro no EAS - reexecuções sem corrigir a causa raiz ocultam bugs do produto.

Notas do React Native

// Prefira seletores estáveis que o Maestro possa direcionar
<Pressable
  testID="sign-in-button"
  accessibilityLabel="Sign in"
  onPress={handleSignIn}
>
  <Text>Sign in</Text>
</Pressable>

- tapOn:
    id: "sign-in-button"

testID mapeia para id no Maestro - use kebab-case consistentemente entre plataformas.
Expo Go vs cliente de desenvolvimento vs builds de lançamento - appId difere; o CI deve testar o mesmo tipo de binário que você envia (perfil e2e-test do EAS, não Expo Go).
Animações - espere pelo conteúdo com extendedWaitUntil em vez de comandos sleep fixos.
Teclado - inputText após focar um campo; no simulador iOS, certifique-se de que o teclado de software esteja habilitado para execuções realistas.

Armadilhas

appId incorreto - O fluxo inicia um aplicativo diferente ou falha imediatamente. Correção: Copie android.package / ios.bundleIdentifier de app.json após eas build:configure, não o slug do Expo.
Testando no Expo Go com appId de produção - O ID do aplicativo do Expo Go é host.exp.exponent, não seu ID de pacote. Correção: Instale um build de desenvolvimento ou de pré-visualização do EAS no emulador antes de maestro test.
Mega-fluxos difíceis de depurar - Um arquivo YAML cobrindo onboarding → paywall → configurações oculta qual etapa falhou. Correção: Uma jornada por arquivo; compartilhe o login via runFlow.
Asserções de string exata frágeis - "Welcome" falha quando a cópia se torna "Welcome!" ou inclui espaço em branco no final. Correção: Asserções de Regex (Welcome!, Welcome.*) e testID para toques críticos.
Estado de backend compartilhado entre fluxos - Execuções paralelas de CI modificam o mesmo usuário de teste. Correção: Tenants de teste dedicados, scripts de semente idempotentes ou contas por execução.
Sem espera por conteúdo assíncrono - assertVisible é executado antes que a busca seja concluída - falhas intermitentes. Correção: extendedWaitUntil ou assertVisible após um indicador de carregamento estável desaparecer.
Assumir que o Maestro substitui o Jest - E2E é lento e não cobre todos os ramos. Correção: Mantenha testes unitários/de componente (Configuração do Jest para Expo, RNTL); use o Maestro para caminhos críticos finos.

Alternativas

Alternativa	Use Quando	Não Use Quando
Maestro	E2E amigável a YAML, autoria rápida, integração EAS Expo	Você precisa de hooks nativos profundos de sincronização dentro do aplicativo
Detox	Testes de caixa cinza esperando ociosidade JS/nativa	Equipe quer código de teste nativo zero e configuração mínima
Checklist de QA Manual	Passagens exploratórias antes de lançamentos importantes	Regressão em cada PR - não escala
RNTL + `renderRouter`	Lógica de rota sem custo de emulador	Diálogos de permissão do sistema operacional ou gestos reais
Appium	Padrão corporativo cross-stack já em vigor	Equipe Expo Greenfield quer a menor cerimônia

FAQs

Como instalo o Maestro localmente?

Siga Instalando o Maestro CLI. Você precisa de um emulador/simulador iniciado com o binário do seu aplicativo instalado antes de maestro test.

Onde os arquivos de fluxo residem?

Convenção: .maestro/ na raiz do projeto (irmão do eas.json). Nomeie os fluxos por jornada (login.yml, checkout-guest.yml), não por número de sprint.

Qual é o separador --- em fluxos YAML?

Linhas acima de --- são configurações (appId, name opcional, env). Linhas abaixo são a lista de comandos executados em ordem.

Como executo todos os fluxos?

maestro test .maestro/

Executa todos os fluxos no diretório. Em CI, liste caminhos explícitos em flow_path para que rascunhos experimentais não sejam capturados acidentalmente.

Como o EAS sabe qual binário de aplicativo instalar?

O job maestro build_id referencia o artefato do job build no mesmo workflow. Compile com o perfil e2e-test para que a saída seja um .apk instalável ou .app de simulador.

Posso executar o Maestro em iOS e Android em um único workflow?

Use arquivos de workflow (ou jobs) separados por plataforma - platform: ios vs platform: android compilam artefatos diferentes. Compartilhe fluxos YAML quando a paridade da UI for próxima; ramifique com fluxos específicos da plataforma quando não for.

Como direciono um elemento com texto duplicado?

- tapOn:
    id: "submit-button"

Adicione testID no React Native. Prefira id em vez de toques de coordenada - coordenadas quebram em diferentes tamanhos de tela.

Como lidar com spinners de carregamento?

- extendedWaitUntil:
    visible: "Dashboard"
    timeout: 20000

Espere pela tela pós-carregamento - não pelo spinner em si - para que redes rápidas não falhem na visibilidade do spinner.

O Maestro pode preencher campos de texto seguro?

Sim - inputText funciona em campos seguros focados. Certifique-se de que o campo seja tocado primeiro. Teste em ambas as plataformas; o comportamento do teclado difere no simulador iOS.

Como reutilizo uma sequência de login?

# .maestro/subflows/login.yml
- tapOn: "Sign in"
- inputText: "test@example.com"
# ...
 
# .maestro/checkout.yml
- runFlow: subflows/login.yml
- tapOn: "Checkout"

Mantenha sub-fluxos em .maestro/subflows/ e referencie com runFlow.

Qual perfil de build o e2e-test deve usar?

withoutCredentials: true - builds internos de CI sem configuração de assinatura de loja.
Android buildType: "apk" - instalável no emulador sem a dança de assinatura da Play.
iOS simulator: true - produz um .app de simulador, não um IPA da App Store.

Maestro vs Detox para Expo SDK 57?

Maestro: YAML, caixa-preta, tipo de job EAS Workflow, baixa configuração. Detox: testes JS, sincronização de caixa cinza, configuração de build nativa - veja Detox E2E quando precisar de IDs de teste no aplicativo e sincronização ociosa.

Como reduzo falhas em CI?

Fixe o nível da API do emulador em CI para corresponder ao desenvolvimento local.
Alimente dados de backend antes dos fluxos.
Use extendedWaitUntil para telas vinculadas à rede.
Divida fluxos longos; políticas de retentativa ajudam, mas primeiro corrija os problemas de tempo raiz.

Devo commitar .maestro no git?

Sim - os fluxos são código-fonte. Revise-os como alterações de aplicativo. Exclua a saída de depuração local do Maestro ou gravações de tela se sua equipe as gerar durante o desenvolvimento.

Quantos fluxos E2E eu preciso?

Cubra apenas os caminhos críticos - autenticação, pagamento, perda de dados, telas regulatórias. A cobertura exaustiva de ramos permanece no Jest. Veja Noções Básicas de Teste Móvel para o equilíbrio da pirâmide.

Relacionados

Noções Básicas de Teste Móvel - onde o E2E se encaixa na pirâmide de testes
Configuração do Jest para Expo - testes unitários rápidos que o Maestro não substitui
React Native Testing Library - testes de componente abaixo do E2E
Detox E2E - alternativa de caixa cinza quando o Maestro não é suficiente
Integração com GitHub Actions - runners de CI não-EAS com Maestro
Noções Básicas de EAS Build - perfis de build que alimentam jobs E2E

Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (expo ~57.0.4).

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

# .maestro/login.yml
appId: com.yourcompany.yourapp
---
- launchApp
- tapOn: "Sign in"
- tapOn:
    id: "email-input"
- inputText: "alex@example.com"
- tapOn: "Continue"
- assertVisible: "Welcome back.*"

// eas.json (excerto)
{
  "build": {
    "e2e-test": {
      "withoutCredentials": true,
      "ios": { "simulator": true },
      "android": { "buildType": "apk" }
    }
  }
}

# .eas/workflows/e2e-test-android.yml
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
    params:
      build_id: ${{ needs.build_android_for_e2e.outputs.build_id }}
      flow_path: [".maestro/login.yml"]

Quando usar isso:

Jornadas críticas do usuário: login, checkout, onboarding, deep links de notificação push.
Fluxos que cruzam o chrome nativo - permissões do sistema operacional, barras de abas, teclados do sistema.
Portões de regressão antes da submissão para a loja (complementa Melhores Práticas de Teste).
Equipes que desejam que não desenvolvedores leiam e estendam cenários de teste em YAML.

Exemplo de Trabalho

Layout do projeto:

your-expo-app/
  .maestro/
    home.yml
    explore-collapsible.yml
  .eas/
    workflows/
      e2e-test-android.yml
      e2e-test-ios.yml
  eas.json
  app.json

// app.json (excerto - fonte da verdade do appId)
{
  "expo": {
    "name": "Tasks Demo",
    "slug": "tasks-demo",
    "ios": { "bundleIdentifier": "com.example.tasksdemo" },
    "android": { "package": "com.example.tasksdemo" }
  }
}

# .maestro/home.yml
appId: com.example.tasksdemo
---
- launchApp
- assertVisible: "Welcome!"
- tapOn: "Tasks.*"
- assertVisible: "No tasks yet"

# .maestro/explore-collapsible.yml
appId: com.example.tasksdemo
---
- launchApp
- tapOn: "Explore.*"
- tapOn: ".*File-based routing"
- assertVisible: "This app has two screens.*"
- scrollUntilVisible:
    element: "Learn more"
    direction: DOWN

// eas.json
{
  "build": {
    "e2e-test": {
      "withoutCredentials": true,
      "ios": {
        "simulator": true
      },
      "android": {
        "buildType": "apk"
      }
    }
  }
}

# .eas/workflows/e2e-test-android.yml
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
    params:
      build_id: ${{ needs.build_android_for_e2e.outputs.build_id }}
      flow_path:
        - ".maestro/home.yml"
        - ".maestro/explore-collapsible.yml"

# Execução local (após instalar o Maestro CLI e um build de depuração no emulador/simulador)
maestro test .maestro/home.yml
maestro test .maestro/
 
# Acionar EAS Workflow manualmente
npx eas-cli@latest workflow:run .eas/workflows/e2e-test-android.yml

O que isso demonstra:

appId corresponde a android.package / ios.bundleIdentifier de app.json.
Correspondências de Regex - Tasks.* e Explore.* toleram pequenas alterações de rótulo e diferenças de texto entre plataformas.
Perfil de build e2e-test - produz .apk (Android) e .app de simulador (iOS) sem credenciais de loja.
Job maestro do EAS - instala o artefato de build do build_id e executa os fluxos de flow_path.
Fluxos independentes - cada arquivo YAML é uma jornada; falhas identificam a tela quebrada.

Mergulho Profundo

Como Funciona

O Maestro CLI se conecta a um emulador/simulador em execução (ou dispositivo físico) e inicia o aplicativo por appId.
Cada fluxo é uma lista ordenada de comandos (launchApp, tapOn, inputText, assertVisible, scrollUntilVisible, …) executados contra a árvore de UI ao vivo.
O Maestro usa rótulos de acessibilidade e texto visível - adicione testID / accessibilityLabel no React Native quando a cópia sozinha for ambígua.
EAS Workflows type: build produz um binário instalável; type: maestro baixa esse binário para o runner e executa os fluxos - sem upload manual de artefatos.
Os fluxos são caixa-preta - eles não importam seu JS; mudar a implementação não quebra os testes se a UI visível para o usuário permanecer a mesma.

Comandos de Fluxo Comuns

Comando	Propósito
`launchApp`	Inicialização fria (ou retomada) do aplicativo em teste
`tapOn`	Tocar por texto, id ou regex (`"Sign in"`, `id: "submit-btn"`)
`inputText`	Digitar no campo focado
`assertVisible` / `assertNotVisible`	Falhar rapidamente se a cópia ou id estiverem faltando
`scrollUntilVisible`	Rolar até o elemento aparecer - listas e telas longas
`runFlow`	Compor sub-fluxos para etapas de login compartilhadas
`extendedWaitUntil`	Esperar pelo elemento com timeout - portões de carregamento assíncronos

Opções de Integração com CI

Abordagem	Prós	Contras
Job `maestro` do EAS Workflows	Integração nativa com Expo, build + teste vinculados	Requer assinatura do EAS e configuração de workflow
GitHub Actions + `maestro test`	Controle total dos runners	Você gerencia a inicialização do emulador, instalação do APK e cache
`maestro test` local antes do PR	Feedback mais rápido	Não imposto a menos que o CI também seja executado

O Expo documenta o caminho do EAS Workflows em Executar testes E2E no EAS Workflows com Maestro.

Controles para Testes Instáveis

# .maestro/checkout.yml
appId: com.example.tasksdemo
---
- launchApp
- extendedWaitUntil:
    visible: "Catalog"
    timeout: 15000
- tapOn:
    id: "product-card-1"
- assertVisible: "Add to cart"

Técnica	Quando
Regex (`Welcome.*`)	Pequenas diferenças de pontuação ou strings de plataforma
`extendedWaitUntil`	Telas carregadas pela rede, transição splash → home
`id:` / `testID`	Texto visível duplicado na tela
Fluxos curtos e focados	Isolar falha - evitar mega-fluxos de 40 etapas
`runFlow` para login uma vez	DRY sem mesclar asserções não relacionadas
Contas de teste estáveis / dados de semente	O estado do backend não deve depender da produção

Acompanhe a taxa de instabilidade ao longo do tempo com Insights do Maestro no EAS - reexecuções sem corrigir a causa raiz ocultam bugs do produto.

Notas do React Native

// Prefira seletores estáveis que o Maestro possa direcionar
<Pressable
  testID="sign-in-button"
  accessibilityLabel="Sign in"
  onPress={handleSignIn}
>
  <Text>Sign in</Text>
</Pressable>

- tapOn:
    id: "sign-in-button"

testID mapeia para id no Maestro - use kebab-case consistentemente entre plataformas.
Expo Go vs cliente de desenvolvimento vs builds de lançamento - appId difere; o CI deve testar o mesmo tipo de binário que você envia (perfil e2e-test do EAS, não Expo Go).
Animações - espere pelo conteúdo com extendedWaitUntil em vez de comandos sleep fixos.
Teclado - inputText após focar um campo; no simulador iOS, certifique-se de que o teclado de software esteja habilitado para execuções realistas.

Armadilhas

appId incorreto - O fluxo inicia um aplicativo diferente ou falha imediatamente. Correção: Copie android.package / ios.bundleIdentifier de app.json após eas build:configure, não o slug do Expo.
Testando no Expo Go com appId de produção - O ID do aplicativo do Expo Go é host.exp.exponent, não seu ID de pacote. Correção: Instale um build de desenvolvimento ou de pré-visualização do EAS no emulador antes de maestro test.
Mega-fluxos difíceis de depurar - Um arquivo YAML cobrindo onboarding → paywall → configurações oculta qual etapa falhou. Correção: Uma jornada por arquivo; compartilhe o login via runFlow.
Asserções de string exata frágeis - "Welcome" falha quando a cópia se torna "Welcome!" ou inclui espaço em branco no final. Correção: Asserções de Regex (Welcome!, Welcome.*) e testID para toques críticos.
Estado de backend compartilhado entre fluxos - Execuções paralelas de CI modificam o mesmo usuário de teste. Correção: Tenants de teste dedicados, scripts de semente idempotentes ou contas por execução.
Sem espera por conteúdo assíncrono - assertVisible é executado antes que a busca seja concluída - falhas intermitentes. Correção: extendedWaitUntil ou assertVisible após um indicador de carregamento estável desaparecer.
Assumir que o Maestro substitui o Jest - E2E é lento e não cobre todos os ramos. Correção: Mantenha testes unitários/de componente (Configuração do Jest para Expo, RNTL); use o Maestro para caminhos críticos finos.

Alternativas

Alternativa	Use Quando	Não Use Quando
Maestro	E2E amigável a YAML, autoria rápida, integração EAS Expo	Você precisa de hooks nativos profundos de sincronização dentro do aplicativo
Detox	Testes de caixa cinza esperando ociosidade JS/nativa	Equipe quer código de teste nativo zero e configuração mínima
Checklist de QA Manual	Passagens exploratórias antes de lançamentos importantes	Regressão em cada PR - não escala
RNTL + `renderRouter`	Lógica de rota sem custo de emulador	Diálogos de permissão do sistema operacional ou gestos reais
Appium	Padrão corporativo cross-stack já em vigor	Equipe Expo Greenfield quer a menor cerimônia

FAQs

Como instalo o Maestro localmente?

Siga Instalando o Maestro CLI. Você precisa de um emulador/simulador iniciado com o binário do seu aplicativo instalado antes de maestro test.

Onde os arquivos de fluxo residem?

Convenção: .maestro/ na raiz do projeto (irmão do eas.json). Nomeie os fluxos por jornada (login.yml, checkout-guest.yml), não por número de sprint.

Qual é o separador --- em fluxos YAML?

Linhas acima de --- são configurações (appId, name opcional, env). Linhas abaixo são a lista de comandos executados em ordem.

Como executo todos os fluxos?

maestro test .maestro/

Executa todos os fluxos no diretório. Em CI, liste caminhos explícitos em flow_path para que rascunhos experimentais não sejam capturados acidentalmente.

Como o EAS sabe qual binário de aplicativo instalar?

O job maestro build_id referencia o artefato do job build no mesmo workflow. Compile com o perfil e2e-test para que a saída seja um .apk instalável ou .app de simulador.

Posso executar o Maestro em iOS e Android em um único workflow?

Como direciono um elemento com texto duplicado?

- tapOn:
    id: "submit-button"

Adicione testID no React Native. Prefira id em vez de toques de coordenada - coordenadas quebram em diferentes tamanhos de tela.

Como lidar com spinners de carregamento?

- extendedWaitUntil:
    visible: "Dashboard"
    timeout: 20000

Espere pela tela pós-carregamento - não pelo spinner em si - para que redes rápidas não falhem na visibilidade do spinner.

O Maestro pode preencher campos de texto seguro?

Sim - inputText funciona em campos seguros focados. Certifique-se de que o campo seja tocado primeiro. Teste em ambas as plataformas; o comportamento do teclado difere no simulador iOS.

Como reutilizo uma sequência de login?

# .maestro/subflows/login.yml
- tapOn: "Sign in"
- inputText: "test@example.com"
# ...
 
# .maestro/checkout.yml
- runFlow: subflows/login.yml
- tapOn: "Checkout"

Mantenha sub-fluxos em .maestro/subflows/ e referencie com runFlow.

Qual perfil de build o e2e-test deve usar?

withoutCredentials: true - builds internos de CI sem configuração de assinatura de loja.
Android buildType: "apk" - instalável no emulador sem a dança de assinatura da Play.
iOS simulator: true - produz um .app de simulador, não um IPA da App Store.

Maestro vs Detox para Expo SDK 57?

Como reduzo falhas em CI?

Fixe o nível da API do emulador em CI para corresponder ao desenvolvimento local.
Alimente dados de backend antes dos fluxos.
Use extendedWaitUntil para telas vinculadas à rede.
Divida fluxos longos; políticas de retentativa ajudam, mas primeiro corrija os problemas de tempo raiz.

Devo commitar .maestro no git?

Sim - os fluxos são código-fonte. Revise-os como alterações de aplicativo. Exclua a saída de depuração local do Maestro ou gravações de tela se sua equipe as gerar durante o desenvolvimento.

Quantos fluxos E2E eu preciso?

Relacionados

Noções Básicas de Teste Móvel - onde o E2E se encaixa na pirâmide de testes
Configuração do Jest para Expo - testes unitários rápidos que o Maestro não substitui
React Native Testing Library - testes de componente abaixo do E2E
Detox E2E - alternativa de caixa cinza quando o Maestro não é suficiente
Integração com GitHub Actions - runners de CI não-EAS com Maestro
Noções Básicas de EAS Build - perfis de build que alimentam jobs E2E

Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (expo ~57.0.4).

Maestro E2E

Buscar na documentação

Maestro E2E