Case Avenue: Execução de Testes Automatizados Com Maestro Framework em um Device Farm Interno
O Contexto
A execução de testes automatizados para aplicativos mobile é um desafio constante, especialmente quando se busca equilíbrio entre custo, escalabilidade e controle sobre a infraestrutura de testes. Na Avenue, estamos usando o Maestro como framework para automação mobile e enfrentamos limitações ao utilizar soluções de cloud do Maestro e decidimos implementar uma abordagem inovadora: um device farm interno para execução dos testes automatizados utilizando framework.
Qual era nosso objetivo principal ?
O principal objetivo era garantir que a regressão da próxima versão do app fosse feita de forma automatizada, reduzindo o tempo de validação sem comprometer a qualidade.
Os nossos principais desafios
Integrar os testes a um device farm sem depender da infraestrutura do Maestro Cloud.
Evitar a necessidade de migração para Appium, mantendo os testes no Maestro.
Reduzir custos, já que o Maestro Cloud cobrava $250 por device executado.
Após diversas POCs (Provas de Conceito), concluímos que o Maestro cumpre o que promete, em relação aos demais frameworks para automação de testes para apps em Flutter.
Maestro is built on learnings from its predecessors (Appium, Espresso, UIAutomator, XCTest, Selenium, Playwright) and allows you to easily define and test your Flows.
Histórico
Antes da automação dos testes, o lançamento de uma nova versão do app levava dias e frequentemente exigia hotfixes para corrigir problemas pós-release.
Com a automação dos principais cenários de regressão, as liberações passaram a ser feitas em poucas horas, e a incidência de hotfixes reduziu drasticamente.
Atualmente, temos 79 cenários automatizados rodando em quatro simuladores iOS ou Androids, com um tempo médio de execução de 50 minutos.
(Nota: Neste post, não abordaremos a estrutura do repositório, pois esse não é o foco.)
Como chegamos à solução do Device Farm Interno?
No início da automação, o número de flows (como são chamadas as specs no Maestro) era pequeno. Naquela época, o Maestro Cloud oferecia um “pool compartilhado de devices”, permitindo que nossos flows fossem executados simultaneamente em vários dispositivos disponíveis. Isso tornava o modelo de cobrança de $0.10 por flow bastante vantajoso.
No entanto, a situação começou a se deteriorar quando o Maestro Cloud mudou para um modelo de devices dedicados. Para manter a paralelização dos testes, precisaríamos adquirir mais dispositivos, e o custo aumentou drasticamente de $0.10 por flow para $250 por device.
Adquirimos um segundo simulador por $250/mês, mas ainda assim enfrentamos instabilidades, lentidão e um suporte limitado. Isso ocorreu porque a equipe do Maestro estava focada no lançamento do Robin (que mudou o nome para Maestro Cloud novamente), deixando pouco espaço para resolver nossos problemas.
Diante desse cenário, avaliamos outras opções de device farms, mas encontramos dois grandes obstáculos:
1. A maioria das soluções não possuía integração com o Maestro.
2. As opções disponíveis eram muito caras.
A solução encontrada foi adquirir um Mac Mini e transformá-lo em nosso próprio dumb runner.
Solução: Device Farm Interno com Maestro Framework
Desenvolvemos um device farm interno utilizando um Mac Mini como servidor de execução de testes (dumb runner). Esse ambiente foi integrado ao pipeline de CI/CD, garantindo que os testes fossem executados de forma automatizada e eficiente.
Arquitetura da Solução
A infraestrutura do device farm interno é composta pelos seguintes componentes:
Infraestrutura Local
Mac Mini M2 Pro (32GB RAM, 1TB SSD) como servidor de execução dos testes.
Execução de testes em múltiplos emuladores Android e simuladores iOS.
Pipeline GitHub Actions para disparo automático dos testes.
2. Componentes do Sistema
API Interna de Automação: Gerencia upload de builds, execução de testes e coleta de resultados.
GitHub Actions: Automatiza a comunicação entre a API e o pipeline de CI/CD.
Banco de Dados: Armazena informações sobre execuções dos testes para análise posterior.
Monitoramento e Relatórios: DataDog para coleta de logs e métricas de desempenho.
Notificações no Slack, incluindo vídeos e logs dos testes executados.
3. Comunicação em Tempo Real
WebSocket para manter uma conexão bidirecional entre o servidor e os clientes, permitindo:
Atualizações instantâneas sobre o status dos testes.
Redução de latência e eliminação da necessidade de polling.
Monitoramento do progresso dos testes em tempo real via dashboard.
Reports:
Execução dos Testes
Os testes são executados em dois momentos principais:
✅ Nightly Tests: Rodam em um horário especifico todos os dias, garantindo estabilidade contínua.
✅ Pré-Release: Executados antes de cada lançamento para validar a regressão.
E quanto a resultados flaky?
Sim, enfrentamos alguns testes instáveis, principalmente por dois motivos:
1. Ambiente de testes dinâmico: Times fazem deploy contínuo no ambiente, causando inconsistências.
2. Desatualização de testes: Algumas squads esquecem de atualizar os testes após mudanças no app.
Desafios da Arquitetura do Device Farm Interno
Criar essa infraestrutura trouxe diversos desafios técnicos e operacionais:
1. Desenvolvimento e Integração
Criar API, Actions, Web, WebSocket, monitoramento e reports foi complexo, pois não havia uma solução pronta, como o Cypress Cloud.
2. Dependências de Infraestrutura
Precisamos envolver do time de Infra e Segurança para garantir que a rede e o servidor estivessem configurados corretamente.
Falta de energia e internet no escritório podem derrubar o Mac Mini.
3. Manutenção do Mac Mini
Necessidade de alguém no escritório para manutenção caso o servidor trave.
Não é possível simular muitos devices simultaneamente no Mac Mini.
Limite de paralelização: O Mac Mini não suporta múltiplas execuções em paralelo (ex.: 3 simuladores iOS + 3 Androids ao mesmo tempo). A solução para isso poderia ser criar um rack com devices fisicos plugados ao mac mini, mas não tentamos.
Exige um responsável diário para acompanhar o funcionamento do device farm.
4. Diretrizes da Empresa
Nossa empresa prioriza soluções cloud, o que pode inviabilizar o projeto no futuro.
Benefícios da Implementação
✔ Aprendizado Técnico: Criamos e mantivemos uma infraestrutura completa de testes.
✔ Controle Total: Melhorias são implementadas conforme nossas necessidades.
✔ Redução de Custos: Investimento único no Mac Mini, eliminando cobranças recorrentes da cloud.
✔ Inovação: Fizemos o que nenhum device farm famosinho ainda fez
Vale a pena investir em um Device Farm Interno?
A resposta depende do contexto de cada empresa:
✅ Custo: Se o uso da cloud for caro, pode valer a pena.
✅ Escalabilidade: Se a empresa tem alto volume de testes, precisa avaliar se o hardware dá conta.
✅ Necessidade de iOS: Se os testes são apenas para Android, um servidor Linux pode ser mais barato.
✅ Equipe dedicada: O projeto exige 4–8 horas diárias para desenvolvimento e manutenção.
Próximos passos:
Manter uma infraestrutura própria pode se tornar um desafio a longo prazo, especialmente para empresas que precisam de escalabilidade e suporte contínuo. Apesar da eficiência e autonomia oferecidas pelo device farm interno, decidimos retornar para a solução do Maestro Cloud, que atualmente está mais estável. Essa mudança eliminará a necessidade de gerenciamento físico do hardware e garantirá maior escalabilidade.
Inicialmente, iremos contratar um plano com 6 devices iOS e 6 devices Android, e os testes serão executados por tags nos PRs de feature flag antes de serem mesclados na branch develop. Custo médio do Maestro Cloud $3.000 + $500 do SSO
O que sabemos até agora:
Quero usar apenas 3 devices para rodar apenas 6 cenários da tag smoke consigo?
Não. O Maestro Cloud não permite o uso do shard-split, ou seja, não é possível distribuir os testes para rodar em um número específico de devices sem que todos os dispositivos disponíveis na conta (iOs ou Andoid) sejam utilizados.
Como contornar essa limitação?
Para rodar os testes em um número específico de devices, será necessário:
1. Solicitar novas contas no Maestro Cloud com apenas a quantidade de devices que você deseja utilizar.
2. Gerenciar essas contas manualmente, garantindo que os testes sejam direcionados corretamente.
Isso exige um fluxo de gerenciamento mais detalhado, como o ilustrado na imagem abaixo.
(Nota: Ainda estamos em processo de desenvolvimento e negociação para esse novo processo)
Conclusão
A implementação de um device farm interno para execução de testes mobile com o Maestro Framework na Avenue trouxe grandes aprendizados, permitiu redução de custos e proporcionou maior controle sobre a infraestrutura de testes. No entanto, essa abordagem também exigiu esforços contínuos de manutenção e um recurso dedicado para garantir sua estabilidade.
Se sua empresa busca independência e deseja evitar os altos custos recorrentes de serviços em nuvem, essa estratégia pode ser uma alternativa viável. Porém, é fundamental realizar uma avaliação cuidadosa considerando escalabilidade, suporte e custo-benefício antes da implementação.
Caso tenha dúvidas, queira trocar experiências ou compartilhar insights sobre essa abordagem, sinta-se à vontade para mandar uma mensagem na DM ou deixar um comentário!