São necessários testes automáticos em projetos. Mas, como se costuma dizer, a automação no sabor e na cor pode ser diferente. Chegamos a um projeto em que já havia autotestes e conseguimos melhorar a cobertura e acelerar a aprovação de testes sem uma revolução fundamental. Sob o gato sobre como nós fizemos isso.
Algumas palavras sobre o projeto
Embora não possamos divulgar os detalhes do projeto devido à NDA, em termos gerais, a tarefa foi a seguinte. Ingressamos no desenvolvimento do serviço API fintech, que interagiu com o banco de dados, retornando os objetos financeiros necessários (preços, tarifas, etc.). Nossa tarefa era testar clientes móveis para esse serviço - aplicativos móveis da Web e nativos.
A automação de testes neste projeto foi desenvolvida gradualmente, juntamente com a complexidade do serviço. Provavelmente, esse foi o período de testes de ponta a ponta que apareceram ao mesmo tempo, que encontramos no projeto. A maioria deles não funcionou nessa época, porque o serviço havia mudado e não havia ninguém para dar suporte aos testes - o único engenheiro de automação saiu do projeto muito antes de chegarmos.
Mesmo os testes que parecem corresponder à funcionalidade às vezes caíam devido à confusão com versões ou inacessibilidade de recursos externos. Para o teste, foi usada uma infraestrutura separada - bancos de teste, onde as versões necessárias foram implantadas para experimentos. Diferentes grupos de trabalho tiveram acesso a ele e nem sempre atuavam em conjunto. Como resultado das ações de um grupo, alguma API importante usada por nosso serviço pode cair, por causa da qual até um teste de trabalho parou de passar. I.e. o teste não mostrou mais a capacidade de manutenção do próprio serviço, mas relacionado à infraestrutura de teste como um todo.
Como chegamos ao caos
Parece que nessa situação é necessário abandonar todas as conquistas antigas e construir os testes novamente. Mas agimos mais "humanamente". A estrutura de teste em si foi preservada, com foco na solução de problemas específicos - passagem lenta dos testes, instabilidade e cobertura insuficiente dos casos de teste. Para cada um deles havia uma solução.
Refatoração
Primeiro, reformulamos parcialmente o código de testes antigos, contando com padrões de design mais modernos.
Parte do código legado teve que ser removido - era muito difícil de manter. Em outra parte, captamos todas as fraquezas - substituímos o sono padrão por garçons normais, fizemos os preparativos para todos os testes na configuração global por meio de anotações dos participantes do teste, etc. Muitas pequenas etapas reduziram a média do teste de ponta a ponta de 3-4 para 1-2 minutos.
Abordagem atômica
Para acelerar a criação de novos testes e simplificar o suporte dos antigos, passamos de casos complexos de ponta a ponta.
Pessoalmente, não tenho nada contra os testes de ponta a ponta, no entanto, no caso em que você precisa verificar uma tela específica (ou mesmo parte das informações nela), passar por todas as etapas, começando com a autorização do usuário, é muito caro. Imagine que estamos testando uma loja on-line e precisamos verificar apenas o cheque que será enviado ao comprador após a compra de um determinado produto. Em vez de buscar apenas uma tela do sistema, acessávamos login e senha, selecionávamos o produto, confirmamos a compra etc. - executaria muitas etapas que não estão relacionadas a uma tarefa de teste específica. Mas cada passo leva tempo. Mesmo com toda a otimização realizada, o lançamento do teste de ponta a ponta levou até 2 minutos, enquanto a verificação de uma tela específica levou apenas 10 segundos. Portanto, sempre que possível, passamos a tais verificações "atômicas", referindo-nos apenas à tela que nos interessa como parte do caso de teste.
Ao longo do caminho, apenas para comparação de tela, implementamos o teste de instantâneo, que permite verificar a maior parte da interface do usuário. Tendo testes e código do aplicativo em um repositório, podemos usar os métodos desse aplicativo nos testes, ou seja, levante todas as telas necessárias neste processo. Assim, podemos encontrar erros na comparação de capturas de tela de teste com referências.
Agora, temos cerca de 300 testes de captura instantânea, e seu número está aumentando gradualmente, pois essa abordagem pode reduzir significativamente o tempo necessário para verificar a versão final antes de enviá-la para produção. Todo esse conjunto de testes inicia automaticamente quando a solicitação pull é aberta e é executada em 40 minutos - para que os desenvolvedores recebam rapidamente comentários sobre os problemas na ramificação atual.
Obviamente, vários testes de ponta a ponta foram preservados. Você não pode ficar sem eles onde precisa verificar grandes cenários de negócios, mas faz sentido executá-los quando todos os detalhes já tiverem sido verificados.
Zombando
Para excluir a influência de uma bancada de teste instável no resultado do lançamento de nossos testes, lançamos um servidor simulado. Sobre as decisões que consideramos e por que escolhemos o Okhttpmockwebserver,
eu já escrevi no Habré .
Como resultado, a participação dos que caíram episodicamente devido a causas externas dos testes diminuiu significativamente.
Kotlin DSL
Paralelamente, tornamos os testes mais legíveis.
Os envolvidos no teste de interface do usuário sabem o quão difícil é encontrar a verdade entre vários localizadores no longo "calçado" do teste (especialmente no estágio em que ainda eram testes de ponta a ponta). É fácil navegar neles quando você está em um projeto há dois anos e mesmo no meio da noite consegue se lembrar do que é o quê. Mas se você veio, mudar para o que está acontecendo é uma grande tarefa separada. Para que novas pessoas não precisem lidar com isso todas as vezes, decidimos mudar para o Kotlin DSL. É implementado de maneira bastante simples e possui uma estrutura simples e compreensível. Anteriormente, os testes consistiam em um conjunto de chamadas de baixo nível idênticas - cliques, entrada de texto, rolagens, mas agora tudo isso se transformou em algo mais "comercial" - algo como uma abordagem de BDD. Tudo é visível e compreensível.
Na minha opinião, isso nos fez uma certa reserva para o futuro. Este projeto já enfrentou uma vez a partida de um único engenheiro de automação. Para os testes, isso não terminou da melhor maneira - eles simplesmente pararam de apoiá-los, porque o limite de entrada ficou muito alto. A compreensão de um código tão seco exigia muito tempo e uma certa qualificação. Redesenhamos os testes de forma que seja possível transferir rapidamente pessoas de outros projetos ou de testes manuais para automação a qualquer momento. Quase todo mundo pode escrever os testes mais simples no Kotlin DSL. Portanto, a automação pode deixar a implementação de baixo nível e escrever rapidamente novos testes simples para conectar as pessoas da equipe funcional. Eles têm conhecimento suficiente da lógica de negócios e o projeto se beneficiará do fato de estarem mais envolvidos no processo de escrever autotestes. O Kotlin DSL permite que você descreva os casos de teste exatamente como eles gostariam de ver todas as verificações, deixando a implementação de baixo nível de métodos fora do escopo de seu trabalho.
Em geral, tudo isso tornou possível aumentar a cobertura dos autotestes mais rapidamente. Se antes demoravam 16 a 20 horas para implementar o novo conjunto de testes, a nova abordagem, dependendo da complexidade dos testes, levava de 4 a 12 horas (e os custos de mão-de-obra para suporte eram reduzidos de 16 a 24 para 8 a 12 horas). semana).
Autor do artigo: Ruslan Abdulin.
PS Publicamos nossos artigos em vários sites do Runet. Assine nossas páginas no
VK ,
FB ,
Instagram ou no
canal Telegram para conhecer todas as nossas publicações e outras notícias do Maxilect.
PPS Ajude-nos a tornar os artigos do nosso blog mais interessantes:
docs.google.com/forms/d/e/1FAIpQLSeqnPceNuK-JopYVxgF15gNWLIi5oM_AZesioCDGXhvr7Y7tw/viewform .