Allure-Android. Relatórios informativos para automação móvel

O artigo é publicado em nome de Andrey Ivanov e Ekaterina Bateeva , neifmetus

A automação de aplicativos móveis é uma área relativamente jovem: existem muitos frameworks e muitos projetos enfrentam o problema de escolher o mais "rápido, estável e fácil de usar". Há cerca de dois anos, também enfrentamos a escolha de uma nova ferramenta de automação para testar aplicativos Android.
Todas as ferramentas populares foram, de alguma forma, baseadas no UIAutomator e Espresso, por isso decidimos testá-las em sua forma pura e compará-las com o mesmo Appium (o mais popular) e o seeTest (usado antes, o melhor entre os pagos naquela época).

Das vantagens do Appium, é possível distinguir a API WebDriver usual, a capacidade de usar as linguagens e bibliotecas mais populares. Além disso, é amplamente usado em muitas empresas e permite escrever testes diretamente para plataformas iOS e Android. E, finalmente, esta é uma solução gratuita em caixa - o que poderia ser melhor?

Então pensamos, até descobrirmos as seguintes deficiências:

• baixa estabilidade do Appium Server
• Você não pode interagir com os métodos públicos de Activity (em 2018, Nikolai Abalov, do Badoo, falou sobre a criação de um backdoor no Appium em seu artigo, você pode ler aqui )
• muito inferior na velocidade dos testes de café expresso

Para nós, esses momentos foram críticos, por isso foi decidido montar nosso próprio conjunto de ferramentas em torno do Espresso para criar um ecossistema para testar aplicativos móveis.

Então, o framework foi selecionado, restou encontrar os componentes restantes:

1. Corredor - deve permitir executar testes em paralelo e configurar conjuntos de dispositivos
2. Repórter - deve fornecer um relatório legível que possa ser usado por qualquer membro da equipe

As ferramentas

Tudo estava bem com o corredor, remexendo um pouco no github, o shazam / fork foi escolhido.
Ele permite que você configure convenientemente o pool de dispositivos, fácil de modificar, gera um relatório html simples. O Logcat é aplicado a cada relatório, no caso de um teste de stacktrace e uma falha no vídeo. A gravação de vídeo não funciona corretamente, todos os vídeos têm 1 minuto de duração, às vezes vários testes são gravados no vídeo.



Os relatórios da bifurcação estavam longe do ideal, o usuário final não entendeu o que estava acontecendo no teste apenas pelo nome, sem ter um caso de teste à mão. Eu queria ter etapas com anexos de arquivo que me permitissem estruturar o relatório. A busca por um repórter para testes de instrumentação produziu 2 variantes de colher e pepino. Ambas as opções foram descartadas porque um monte de capturas de tela no caso de colher e bdd do pepino não resolveu o problema completamente ...

Allure parecia a solução mais ideal para o problema:

• aninhamento de etapas que permitem estruturar o relatório
• a capacidade de gravar dados de teste personalizados (capturas de tela, vídeo, número da tarefa, parâmetros de teste)
• visão concisa do relatório

Mas havia uma ressalva: o Allure simplesmente não inicia no Android.

Allure-android

Em conexão com o exposto, decidiu-se escrever uma biblioteca que combina a simplicidade e a elegância do Kotlin, as vantagens da estrutura Allure e pode funcionar em telefones Android. Para conectar a biblioteca, adicione dependências ao módulo no qual os testes de instrumentação estão localizados:

dependencies { androidTestImplementation "ru.tinkoff.allure:allure-android:$allureVersion@aar" androidTestImplementation "ru.tinkoff.allure:allure-common:$allureVersion" androidTestImplementation "ru.tinkoff.allure:allure-model:$allureVersion" } 

Após configurar as dependências, precisamos registrar o AllureRunListener na classe responsável pela execução dos testes do Android.

Existem três maneiras de fazer isso:

1. Adicionar ao build.gradle

    testInstrumentationRunner "ru.tinkoff.allure.android.AllureAndroidRunner" 

2. Adicionar ouvinte aos argumentos no Runner onCreate (argumentos: Bundle)

    arguments.putCharSequence("listener", AllureAndroidListener::class.java.name) 

3. Herdado diretamente de AllureAndroidRunner

Os relatórios de fascínio são baseados na etapa - uma etapa, uma ação atômica que é executada durante um teste. As anotações da estrutura Allure Step e Parameter foram substituídas por uma chamada direta para a função step ().

 inline fun <T : Any?> step(description: String, vararg params: Parameter, block: () -> T): T 

Essa função não apenas substitui duas anotações ao mesmo tempo, mas também aceita um lambda no qual você deve agrupar a lógica de teste. Por exemplo:


Após o início do teste, os relatórios no formato json preparados para o Allure2 aparecerão no telefone na pasta / sdcard / allure-results. Tendo retirado o resultado, a equipe

 adb pull /sdcard/allure-results 

nós podemos gerar um relatório

 allure generate 

Entre os recursos adicionais, podemos distinguir:

• a capacidade de investir passos um no outro
• em qualquer lugar, você pode chamar deviceScreenshot (tag: String) para tirar uma captura de tela que será anexada automaticamente ao relatório na etapa atual
• FailshotRule () - Regra junit4, fará uma captura de tela imediatamente antes da queda

Esta é uma visão geral do uso do Allure na plataforma Android. A solução allure-android está disponível no GitHub , você pode ver em detalhes e participar do desenvolvimento.