- A maneira mais fácil de automatizar testes de UI de aplicativos mobile
- Tem tolerância intrínseca à instabilidade dos elementos de UI
- Como os elementos de UI nem sempre estão na posição esperada, tocar na tela nem sempre funciona
- Busca acomodar a instabilidade dos aplicativos mobile e dos dispositivos e reagir a ela
- Tem tolerância intrínseca a atrasos
- Não é necessário colocar chamadas
sleep() nos testes
- Sabe que o carregamento de conteúdo (por exemplo, via rede) pode levar tempo e espera automaticamente, mas sem esperar mais do que o necessário
- Permite iteração muito rápida
- Os testes são interpretados, então não é preciso compilar
- Pode monitorar continuamente os arquivos de teste e executá-los novamente quando houver mudanças
- Oferece uma sintaxe declarativa e poderosa
- Os testes são definidos em arquivos
yaml
- A configuração é simples
- É um binário único que funciona em qualquer lugar
Opinião do GN⁺
- O Maestro é uma nova ferramenta para automação de testes de aplicativos mobile e busca superar as limitações de ferramentas existentes como Appium, Espresso, UIAutomator e XCTest. Em especial, por ter tolerância intrínseca à instabilidade dos elementos de UI e a atrasos, parece capaz de reduzir problemas que ocorriam com ferramentas anteriores.
- Como usa uma sintaxe declarativa baseada em YAML, até engenheiros de QA que não são desenvolvedores provavelmente conseguirão escrever casos de teste com facilidade. Ainda assim, para quem não está familiarizado com a sintaxe de YAML, pode haver um custo de aprendizado.
- Entre as ferramentas de automação de testes para apps mobile, o Appium é amplamente utilizado. Ele tem a vantagem de oferecer suporte a várias plataformas mobile e linguagens de programação, mas também tem a desvantagem de apresentar alta taxa de falhas nos testes por questões de estabilidade. Será preciso observar até que ponto o Maestro consegue resolver esses problemas do Appium.
- No momento, o Maestro tem boa documentação e também mantém uma comunidade no Slack, então vale considerar sua adoção. Ainda assim, como ainda está em versões iniciais, parece necessário validá-lo suficientemente antes de aplicá-lo em ambiente de produção.
4 comentários
Pelo que testei, dá para fazer rapidinho (da configuração até criar o primeiro YAML de teste, em cerca de 1 hora), então achei bem interessante.
O
maestroé simples e tem muitos pontos positivos. Porém, no Android ainda há um problema com a entrada de texto em coreano. https://github.com/mobile-dev-inc/maestro/issues/146Outro ponto decepcionante é que ele não executa tão rapidamente em comparação com outras ferramentas de teste. Normalmente, ferramentas de teste rodam muito rápido, diferente de usuários reais, então havia o problema de testes falharem de forma flaky se o
waitnão fosse projetado com precisão. Omaestroé tão lento que dá até a impressão de que decidiram resolver isso simplesmente esperando devagar. ^^;;;Por outro lado, em testes de frontend web, a abordagem de aproveitar elementos de acessibilidade vem ganhando popularidade, e isso também acontece no mobile. (consulte https://blog.banksalad.com/tech/test-in-banksalad-ios-2/)
Como o Maestro é muito focado em
texteid, achei difícil diferenciar os papéis delink,buttoneheadingde algo como "lista de produtos". Também senti falta de aspectos que no web podem ser validados comaria-checked,aria-expandede afins.No meu caso, para evitar conflitos de
id, acabei adicionando prefixos aotest-id, e no fim era trabalhoso ter que testar de novo se o elemento obtido dessa forma realmente renderizava otextesperado.Obrigado pelo comentário cheio de insights