Para testes end-to-end (E2E) estáveis, precisamos de um ambiente o mais isolado possível do exterior.  Reduzir a descamação  Testes flaky são testes que falham por motivos não relacionados ao seu código. Eles dificultam o uso do E2E como uma verificação confiável da exatidão do aplicativo. Em casos extremos, testes esquisitos ensinarão sua equipe a ignorar os resultados do E2E. Isso pode matar o esforço de automatizar o controle de qualidade (QA).  A abordagem apresentada aqui aborda duas grandes fontes de possíveis problemas em suas execuções de teste:  Estado armazenado pelo back-end compartilhado por diferentes trabalhos de teste e  Serviços externos sobre os quais você não tem controle.  Existem outras fontes de descamação não afetadas por essa abordagem:  O verdadeiro problema está no aplicativo que apareceu aleatoriamente ou  Os problemas no aplicativo são causados pela velocidade não natural com que o E2E interage com ele.  Alternativa  Antes de minha equipe e eu executarmos meus testes em um contêiner de back-end dedicado, usamos um de nossos servidores que não são de produção. Essa abordagem funcionou bem no estágio de experimentação de nossa solução E2E.  Quando havia apenas alguns testes, não podíamos usar os resultados dos testes para tomar decisões de qualquer maneira.  No entanto, conforme continuamos adicionando mais testes e gerando tempos de execução mais longos, essa abordagem começou a desmoronar. As principais questões foram as seguintes:  Mesmo tentando reverter as mudanças de dados dentro do teste, algumas falhas de teste estavam deixando para trás mudanças inesperadas.  Trabalhos paralelos estavam colidindo. Tarefas de teste diferentes estavam alterando os mesmos estados, o que frequentemente fazia com que uma das tarefas falhasse.  Dockerizar tudo  Uma solução para esse problema foi dedicar um servidor de back-end e um banco de dados separados para cada tarefa de teste. Essa abordagem seria muito desafiadora se não fosse pelo Docker.  Os contêineres do Docker são uma ferramenta perfeita para criar um ambiente contido com tudo o que é necessário para executar um aplicativo:  O sistema operacional certo (ou melhor, a distribuição correta do Linux),  as dependências do sistema, como bibliotecas de manipulação de imagens, etc., e  A versão correta dos intérpretes de linguagem (Python, Node, etc.) ou servidores de banco de dados.  Base de dados  Para seu teste, você pode preparar um contêiner de banco de dados dedicado que vem com dados de teste previsíveis. Dessa forma, você poderá reproduzir exatamente o ponto de partida em cada execução do E2E, tornando seus testes mais estáveis.  Você pode usar tags diferentes para sua imagem do Docker, para controle de versão do banco de dados de teste. O mesmo banco de dados de teste também pode ser usado em um ambiente de desenvolvimento. Para testes manuais em desenvolvimento, você precisa de entidades de exemplo semelhantes às dos testes automatizados.  Processo interno  Se você já usou o Docker para implantar seu back-end, será muito fácil reutilizar a mesma imagem para executar seu E2E. Em minha equipe, implantamos um back-end como contêineres e fornecemos URLs e credenciais de banco de dados como variáveis de ambiente.  A mesma versão do contêiner pode ser implantada na produção ou usada na integração contínua (CI) para executar testes – cada ambiente fornece os valores corretos para conexão com o banco de dados.  Front-end  Dependendo da sua estratégia de implantação, você pode fazer um dos seguintes:  Use os contêineres que você cria como parte da compilação do front-end.  Obtenha os arquivos compilados e verifique se eles estão disponíveis via HTTP para os testes.  No nosso caso, usamos a opção 2: implantamos o aplicativo como arquivos estáticos, então criamos um contêiner dedicado para servir os arquivos construídos durante as execuções do trabalho E2E.  Serviços de trabalho no GitLab  Usamos o GitLab como plataforma para executar nosso CI. Cada trabalho no GitLab é executado dentro de um contêiner com uma imagem de sua escolha. Além do container principal, você pode definir   : Containers adicionais rodando junto com seus testes. A configuração é tão fácil quanto: serviços   <job-name>: services: - name: <image> alias: <container-url>  As opções disponíveis são semelhantes às que você tem no Docker Compose, mas são mais limitadas.  Uma “pegadinha” na configuração do GitLab é definir a variável   como 1 se você quiser permitir que os serviços acessem uns aos outros durante a execução do teste. FF_NETWORK_PER_BUILD  Considere dados ad hoc para isolamento no trabalho  Em algum momento, estávamos executando todos os testes em paralelo dentro de um trabalho. Naquela época, era necessário impor um isolamento ainda mais forte – cada teste usava o mesmo back-end e banco de dados.  Para contornar esse problema, atualizamos nossos testes para depender principalmente dos dados aleatórios que injetamos dentro da seção   dos testes. Isso permitiu que os testes fossem executados sem serem afetados por outras alterações que aconteciam em outros encadeamentos. before  Essa abordagem pode ser um pouco complicada no começo, mas pode fazer sentido dependendo das circunstâncias.  Limpar após cada teste  Mesmo que iniciemos um novo banco de dados para cada trabalho de teste, ainda estamos tentando fazer com que nossos testes deixem o aplicativo no mesmo estado em que o encontraram. Talvez seja um resquício do período em que fazíamos testes em um ambiente compartilhado.  Não é mais crucial, mas ainda pode ajudar durante o desenvolvimento do teste nos seguintes casos:  Quando você executa apenas um teste, o estado que o teste encontra não é diferente de quando você executa todos os testes no arquivo.  Quando você executa novamente o mesmo teste localmente várias vezes, de modo que o banco de dados não seja afetado pelas execuções anteriores  Serviço Externo Simulado  Há casos em que mover serviços para um contêiner não é uma opção. Por exemplo:  Se houver servidores externos que o aplicativo usa diretamente ou por meio de algum proxy de back-end, ou  Você possui servidores que não são possíveis de rodar dentro de um container devido a problemas técnicos.  Em ambos os casos, para isolar as execuções de teste, você pode simular as solicitações que vão para esses serviços. Isso impedirá que serviços externos imprevisíveis afetem os resultados do teste. Uma desvantagem dessa abordagem é que seus testes serão desconectados do contexto no qual seus aplicativos operam.  Com simulações em vigor, seus testes   detectarão casos em que as alterações nesses serviços afetam seu aplicativo. não  Continue aprendendo  Se você estiver interessado em aprender mais sobre testes ou outros tópicos relacionados à programação, inscreva-se   para receber atualizações quando eu publicar conteúdo relacionado. aqui

2022 - HackerNoon Contributor of the Year - Beginners Guide

2022 - HackerNoon Contributor of the Year - Code Quality

2022 - HackerNoon Contributor of the Year - Learning

2022 - the Greatest Storyteller

Newsletter

Senior JS developer

Este áudio é produzido no idioma original da história!

Configurando um ambiente de ponta a ponta perfeitamente isolado

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Aumente sua produtividade com estas 18 ferramentas para desenvolvedores 🚀🔥

Como melhorar seu fluxo de trabalho em 10 vezes: 17 aplicativos essenciais

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Aumente sua produtividade com estas 18 ferramentas para desenvolvedores 🚀🔥

Como melhorar seu fluxo de trabalho em 10 vezes: 17 aplicativos essenciais

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps