Acelere os testes, eles disseram.
E agora, quase meio ano já se passou, quando reescrevemos nossos antigos testes funcionais sem cortes, longos e instáveis e passamos a testes rápidos e independentes de componentes. Portanto, é hora de compartilhar :)
Para quem não sabe, os
testes de componentes são completamente isolados do ambiente global e permitem testar certos casos que um teste de unidade não poderia cobrir.
Seis meses atrás, o lançamento de um recurso costumava levar mais de uma hora, já que o código já foi totalmente testado por um longo tempo, mas o ramo principal não pode obter a construção verde em bambu e surgiu a pergunta: como viver?
De fato, nesse caso, os testes de danos são mais do que bons, mas livrar-se deles e “marcá-los” para os testes está longe de ser a melhor opção :) Então, uma pequena micro-equipe foi organizada pelo líder da equipe:
- Timlida
- Desenvolvedor Backend
- Engenheiro de controle de qualidade
- Admin
Tendo cooperado rapidamente, dividimos nossas tarefas e uma delas era criar um ambiente para escrever testes de componentes. E assim minha jornada começou.
No início do desenvolvimento, tínhamos mais de 140 testes funcionais executados em vários threads em diferentes ambientes (Frontend, Mobile, Backend) e levavam de 5 a 7 minutos; muitas vezes também precisava reiniciá-los para obter uma construção verde. E esses testes não caíram mais por causa do novo código escrito, mas por problemas no ambiente, isto é, em algum lugar a API não respondeu, em algum lugar do microsserviço de teste, etc. Isso interrompeu o trabalho de todo o departamento, pois as assembléias começaram quase a cada 5 a 10 minutos: alguém remontado, alguém introduziu um novo código ...
Após a primeira metade da semana, chegamos à conclusão de que "molharemos" nossa API e serviços de terceiros, o que nos daria um ambiente de teste completamente isolado. Mas surgiu a questão: escrever algo próprio ou ... Então, nesse "ou" tudo terminou - com uma breve pesquisa, no caminho que conheci - um pequeno tempo de operação na forma do servidor Mock "http-api-mock".
O http-api-mock é um servidor de simulação leve e sem instalação, escrito em Go, com boa documentação.
Depois de centenas de tentativas de lançamento, além de geralmente me aprofundar no assunto de mok, ainda consegui reescrever 1 teste funcional, que criou um novo anúncio no site e, depois de passar por todos os círculos do inferno, estava convencido de que o título na página corresponde ao título no corpo do objeto.
Imagine ganhou! O teste reescrito resultou ser três vezes mais rápido que o anterior, pois aqui não verificamos a criação, a moderação, mas retornamos imediatamente o objeto de anúncio desejado do Mock e o vencemos. Essa pequena vitória se tornou um bom incentivo para o desenvolvimento deste tópico. Assim, depois de mais uma semana, tínhamos um novo conjunto de codecepção chamado “component”, que já possuía uma classe auxiliar de base para trabalhar com nosso servidor Mock e foi lançado na época eu na caixa de areia.
A classe auxiliar básica pode criar um anúncio na forma de um arquivo json no diretório de configuração do nosso servidor simulado, fornecer o anúncio desejado por ID etc. Quase uma API.
O resto da magia estava esperando por nós ainda mais - agora restava apenas montar o plano de montagem em bambu. Para que nossos testes agora passem pelo nosso CI&CD.
O administrador nos ajudou nisso - com a configuração do lançamento de todos esses testes no docker, o que permitiu que cada build aumentasse seu contêiner com o servidor Mock e executasse nossos testes em um ambiente completamente isolado, sem implantar nosso código em nenhum back-end de teste, o que também não poderia Não acelere nossos testes.
Para trabalhar toda essa mágica, tivemos que adicionar novos arquivos de configuração com um novo endereço de API e serviços externos, além de criar uma cópia do banco de dados mysql e também criar uma nova tarefa no plano de construção com o lançamento do nosso servidor simulado.
Agora, para o nosso código, existe uma API completamente nova que, independentemente de qualquer problema ambiental, nos dará o que queremos.
O tempo passou, os testes foram reescritos e 140 testes funcionais se transformaram em 103 testes de componentes, que são executados em paralelo em ~ 30 segundos.
Dos profissionais
Muito ágil . Devido ao fato de serem completamente independentes do ambiente de teste, eles não precisam ir muito longe para obter dados.
Estável . Os testes não precisam se preocupar se nossa API ou qualquer outro serviço caiu lá, por isso estamos sempre certos de que o resultado chegará até nós.
Fácil de escrever . Na verdade, no processo de reescrita, muito foi decidido copiando o código do antigo teste funcional para o novo teste de componente e preparando pontos de extremidade para ele no servidor Mock.
Dos menos
Suporte . Agora, todo desenvolvedor que fez alterações na resposta retornada para um endpoint específico na API também vai ao repositório com configurações para o servidor simulado e corrige a resposta lá.
Um monte de arquivos . Eles decidiram armazenar os dados com configurações na forma de arquivos, ou seja, cada resposta para o nó de extremidade fica como um arquivo e pode ser perdida em algum lugar.
Resultados:
TestesForam mais de 140 testes funcionais = 5-7 minutos.
Agora: 103 testes de componentes = ~ 30 segundos.
Construir estabilidadeFoi: Toda terceira assembléia caiu devido a qualquer problema.
Tornou-se: cai somente quando o desenvolvedor quebrou a lógica de algum método.
Nos planos futuros, temos que reescrever os testes de aceitação (GUI) - também executá-los dentro do contêiner e isolá-los do resto do ambiente.