Todo mundo que participou ou participou de autotestes do Android sabe o que é uma dor.
Você se cansa do volume de tarefas e problemas para que as férias não ajudem. As pessoas até desistem por causa de autotestes.
Dor, sofrimento e tormento inevitavelmente levam ao surgimento de algo novo e bonito. Tentamos reunir todos os ancinhos que precisávamos pisar, combinamos nossos esforços com os caras da Avito e da HH e criamos algo que tornaria seu relacionamento com os testes automáticos incomparavelmente melhor e mais proveitoso.
Conheça:
Kaspresso - a estrutura de autoteste que você estava esperando!

Observarei imediatamente que existem dois vídeos de alta qualidade na
rede dedicados ao
Kaspresso e
AdbServer (auxiliar do Kaspresso, mas ao mesmo tempo, um projeto forte e independente):
1.
Dmitry Movchan, Eugene Matsyuk - Como começar a escrever autotestes e não enlouquecer2.
Egor Kournikov - A única coisa que você precisa para testar a interface do usuárioEles descrevem em detalhes a história da criação de bibliotecas: como passamos de resolver um problema para outro, e o que aconteceu no final. Eu recomendo.
Portanto, neste artigo, falarei apenas sobre os principais pontos e fichas, para que você possa entender rapidamente sobre o que é essa estrutura e quais tarefas ela resolve. E coragem e detalhes podem ser encontrados no vídeo e na documentação.
Por que precisamos mesmo de nossa própria estrutura?
Todo desenvolvedor que começa a escrever autotestes inevitavelmente faz perguntas:
- Como começar a escrever autotestes?
- Quais ferramentas escolher?
- O que fazer se não houver ferramenta necessária?
- Quais são as melhores práticas?
A tudo isso, acrescente que cada equipe está tentando resolver esses problemas de alguma maneira, à sua maneira. Como resultado, não há uma resposta única para eles, não há lugar para espreitar como fazê-lo corretamente. Portanto, escrever e dar suporte a autotestes é caro para as empresas, o que põe em causa a viabilidade da automação como tal.
Enquanto isso, a automação de teste busca bons objetivos. Ele permite que você sempre tenha um assistente verde e pronto para o lançamento. E isso significa que você pode lançar a versão rapidamente.
O único problema é encontrar respostas para as perguntas acima. Mas eles são quase os mesmos para todas as equipes. Então, por que não automatizar sua solução?
O que queremos da estrutura?
Vamos revelar um pouco nossas expectativas a partir da estrutura.
Boa legibilidade
Por padrão, apenas a biblioteca Espresso está disponível para nós no Android. É claro que existe Appium + Cucumber, que em teoria permite que você escreva testes em duas plataformas ao mesmo tempo. Mas a comunidade está avançando com confiança em direção ao primeiro instrumento. Não descreverei todos os prós e contras das bibliotecas acima: a rede está cheia de informações sobre isso. Aqui, por exemplo, está um dos links relativamente recentes:
Appium vs Espresso. O que escolher e como usar?Então, Espresso. Não é uma ferramenta ruim, mas sua API é um pouco virada do avesso. Dê uma olhada em um código simples:
@Test fun espressoTest() { onView(allOf(allOf(withId(R.id.espresso), isDescendantOfA(withId(R.id.coffee_variates))), isDescendantOfA(withId(R.id.content)))) .check(matches(withEffectiveVisibility(View.VISIBLE))) }
Você tem que pensar para descobrir, certo?
Os deuses da Tailândia e da Austrália nos apresentaram a biblioteca
Kakao , com a qual você pode entender rapidamente o que está acontecendo em seu teste. Aqui está o mesmo código, mas com Kakao:
@Test fun kakaoTest() { mainScreen { myView.isVisible() } }
Muito melhor Mas agora imagine que você automatizou um caso de teste inteiro. Como seria o código?
@RunWith(AndroidJUnit4::class) class OpenHomeScreenTest: TestCase() { @Test fun test() { MainScreen() { homeButton.click() } HomeScreen() { title { isVisible() hasAnyText() } } } }
O principal problema é que, olhando para este teste, é difícil correlacioná-lo com o caso de teste que você automatizou. Você pode, é claro, adicionar logs ou algo assim. Ou digite dsl, que transforma imediatamente a aparência dos seus testes:
@RunWith(AndroidJUnit4::class) class OpenHomeScreenTest: TestCase() { @Test fun test() { step(“1. Open Home screen”) { MainScreen() { homeButton.click() } } step(“2. Check Home title”) { HomeScreen() { title { isVisible() hasAnyText() } } } } }
Concordo, parece completamente diferente.
Estabilidade
Qualquer biblioteca para testes de interface do usuário falha. A mesma ação pode ser executada 50 vezes com êxito e no 51º intervalo, sem motivo aparente. E na 52ª corrida, está tudo bem novamente. E esse "flacking" pode decentemente estragar seus nervos.
Nós pensamos, por que não tentar interceptar todas as ações do Kakao-Espresso, e já adicionar um comportamento adicional para lidar com esses erros aleatórios.
Foi assim que nasceu a
versão 2.1 da biblioteca Kakao , permitindo a integração em todas as chamadas do Espresso.
Além disso, criamos nossos próprios interceptores, com os quais você pode alterar o comportamento no dial-peer ou, por exemplo, simplesmente registrar. Além disso, esses interceptores são personalizáveis, para que você possa personalizá-los para atender às suas necessidades. Leia mais no
banco dos
réus .
Especificamente, como parte da luta contra testes inadequados - se algumas de suas ações causaram uma exceção, a Kaspresso tentará:
- Scroll. Talvez sua visualização simplesmente não esteja visível na tela.
- Remova o diálogo do sistema que poderia vir de Deus sabe onde.
- Repita uma chamada interrompida por dois segundos.
Com essas etapas, resolvemos completamente o problema com testes inadequados!
Registo
Um dos principais problemas que acompanham os autotestes é a falta de log inteligível, o que é especialmente insuficiente quando o teste falha. Sente-se e pergunte-se o que e como caiu aqui.
Graças à interceptação acima mencionada, conseguimos construir um sistema de registro bastante extenso.
Vamos dar uma olhada em um exemplo:


Por padrão, o Kaspresso registra todas as suas ações, seleciona cada etapa do teste, exibe o tempo de execução, etc.
Adb completo em testes de café expresso
Inicialmente, adb não está disponível nos testes Espresso. Sim, há
shell adb , mas há muito menos funções do que no
adb completo. Mas existem muitas coisas que podem ser úteis nos testes.
Criamos uma biblioteca
AdbServer separada que retornará
adb completo para seus testes! O vídeo acima detalha como lutamos e o que passamos por ele (
um e
dois ).
Trabalhar com sistema operacional Android
As especificidades dos testes da Kaspersky Lab são tais que precisamos trabalhar muito com o sistema operacional Android: definir algumas configurações, fazer upload de arquivos para o sistema etc. Tudo isso nos levou a padronizar todo o nosso trabalho com o sistema, criando um conjunto de interfaces claras, acessível através de um único
dispositivo de classe de ponto de entrada.
O que são essas interfaces e o que elas estão fazendo? Deixe-me dar alguns slides da apresentação de Yegor como uma ilustração:




A documentação está
aqui .
Sob o capô, o AdbServer e o UiAutomator são usados principalmente.
Mas! Se de repente você não estiver satisfeito com a implementação de uma interface, poderá configurá-la através do Configurator.
Captura de tela do DocLoc (documentação e localização)
Em todos os projetos em que há localização, geralmente é necessário fazer capturas de tela em diferentes idiomas para entregá-las ao tradutor como ilustrações. Afinal, é muito difícil fazer uma tradução correta sem ver onde e como uma linha específica é usada. Portanto, quero poder capturar capturas de tela rápida e imediatamente em todos os idiomas. Incluindo capturas de tela das caixas de diálogo do sistema. Você também pode precisar de capturas de tela em telas herdadas e sem refatoração global.
Tudo isso permite que você faça o Kaspresso fora da caixa. Leia mais na
documentação .
Arquitetura e melhores práticas
Uma das principais tarefas do Kaspresso era criar um dsl que o levasse à arquitetura de teste correta e à escrita correta.
Muitas cópias foram quebradas neste tópico, porque você, infelizmente, não encontrará essas regras em nenhum lugar. O máximo que você pode encontrar são artigos sobre o
Objeto de Página .
Portanto, não poupamos esforços e destacamos esses problemas na
documentação e no
vídeo uma vez e no
vídeo dois .
Além disso, Sasha Blinov escreveu um excelente
artigo sobre o DSL Kotlin e testes elegantes . O dsl descrito no artigo é fornecido pela Kaspresso.
De volta à Mobius, propusemos uma opção sobre como acelerar o impacto dos autotestes e integrá-los rapidamente ao PullRequest, contornando os inevitáveis problemas de infraestrutura. Falamos sobre isso em mais detalhes
aqui .
Como conectar e configurar o Kaspresso se você já possui muitos testes
O principal é que, se você já possui muitos testes escritos em Kakao e deseja implementar o Kaspresso, não precisa reescrever nada! Apenas herde suas classes de teste da classe especial TestCase. E isso é tudo!
Foi:
@RunWith(AndroidJUnit4::class) class OpenHomeScreenTest { private val mainScreen = MainScreen() private val homeScreen = HomeScreen() @get:Rule val activityTestRule = ActivityTestRule(MainActivity::class.java, true, false) @Test fun test() { ... } }
Tornou-se:
@RunWith(AndroidJUnit4::class) class OpenHomeScreenTest : TestCase() { private val mainScreen = MainScreen() private val homeScreen = HomeScreen() @get:Rule val activityTestRule = ActivityTestRule(MainActivity::class.java, true, false) @Test fun test() { ... } }
E se você não gosta de herança, use uma classe
TestRule semelhante.
Como já mencionamos, o Kaspresso é uma estrutura muito flexível e personalizável. Todas as configurações estão disponíveis na classe
Kaspresso com o mesmo nome.
A configuração padrão é o padrão. Se você deseja personalizar algo, será algo como isto:
@RunWith(AndroidJUnit4::class) class OpenHomeScreenTest : TestCase( Kaspresso.Builder.default().apply { viewBehaviorInterceptors.add(MyInterceptor()) flakySafetyParams.timeoutMs = 1_000 } ) { private val mainScreen = MainScreen() private val homeScreen = HomeScreen() @get:Rule val activityTestRule = ActivityTestRule(MainActivity::class.java, true, false) @Test fun test() { ... } }
Ou seja, o
Kaspresso.Builder está disponível no
construtor TestCase , onde você define todas as configurações necessárias. Detalhes sobre o configurador estão escritos na
documentação .
Planos imediatos
Em um futuro muito próximo, planejamos adicionar o seguinte:
Exibir etapas de teste no Allure (Olá para os caras do HeadHunter)
Através de um interceptador especial, preparamos dados para a
Maratona . Isso nos permite ver relatórios do Allure da seguinte natureza:

Detalhes no
PR # 4O PS PR já está na versão 1.0.1, agora estamos preparando o PR correspondente no
Marathon .
Pss. É recomendável anexar uma parte específica do log a cada etapa e adicionar uma captura de tela à etapa "caída".
Testando scripts de atualização
Muitas vezes, é necessário verificar a correção das atualizações do aplicativo. Sim, algumas das verificações podem ser transferidas para testes de unidade. Mas gostaríamos de ter calma para toda a aplicação como um todo.
Infelizmente, em um Expresso puro, é impossível fazer isso, porque se reinstalarmos o apk testado, o teste falhará. De alguma forma, você pode tentar enganar o corredor, mas é difícil para mim imaginar como essas melhorias serão e quão estáveis serão.
Portanto, na Kaspresso, estamos preparando uma solução para esse problema, com base no UiAutomator. No entanto, no topo, você terá o mesmo dsl familiar, muito semelhante ao Kakao e com o mesmo suporte para interceptação.
Links úteis
KaspressoAdbServerChat , no qual teremos todo o gosto em responder a todas as suas perguntas
Agradecimentos
Agradecimentos especiais a todos que participaram do desenvolvimento do projeto.
Foi muito difícil, mas muito legal!


Em vez de uma conclusão
Acreditamos que a Kaspresso e o AdbServer tornarão sua vida melhor.
Agradecemos seus comentários, recomendações, Yishuyam e PulRequest!
E não se esqueça de colocar um asterisco, por favor!
PS E no final de uma pequena pesquisa =)