O teste de integração continua sendo uma parte importante do ciclo de produção de CI / CD, incluindo o desenvolvimento de aplicativos em contêiner. Testes de integração, como regra, não são muito longos, mas carregam muito trabalho. Vamos ver como você pode combinar tecnologias e ferramentas de teste de integração com ferramentas de orquestração de contêineres (em particular, com o
Red Hat OpenShift ) para acelerar os testes, aumentar seu dinamismo e usar os recursos com mais eficiência.
Vamos criar testes BDD de integração (
desenvolvimento orientado a comportamento ) usando
Pepino ,
Transferidor e
Selênio e executá-los na plataforma OpenShift usando Zalenium.
Teste de BDD
Ao desenvolver testes de integração, o BDD permite que os analistas de negócios (BAs) criem definições de testes de integração, não apenas programadores. Graças ao BDD, o processo de desenvolvimento pode ser organizado para que requisitos funcionais e definições de testes de integração sejam preparados ao mesmo tempo e ao mesmo tempo criados por analistas de negócios.
Isso é muito melhor do que as abordagens tradicionais, quando você determina primeiro a funcionalidade comercial do aplicativo e, em seguida, o departamento de controle de qualidade (QA) cria testes de integração, conforme mostrado no diagrama abaixo:
E aqui está como fica ao usar o BDD:
Além disso, neste novo esquema, cada iteração normalmente leva menos tempo.
Os analistas de negócios podem criar definições para testes de integração porque o BDD os descreve em uma linguagem
Gherkin simples e compreensível, cujas principais palavras-chave são Dadas, Quando e Depois. Cada afirmação na língua maxixe deve começar com uma dessas palavras.
Por exemplo:Dado que o usuário navegou para a página de login (desde que o usuário tenha acessado a página de login)
Quando o usuário digita nome de usuário e senha
Quando nome de usuário e senha estão corretos
Em seguida, o sistema efetua login (o sistema permite que ele efetue login)Um tempo de execução popular que pode interpretar os testes Gherkin é o
Pepino . Para usar o Pepino, um desenvolvedor deve implementar determinadas funções para que quaisquer diretivas Gherkin possam ser executadas. Pepino tem ligações para muitas linguagens de programação. Os testes são recomendados (mas não obrigatórios) para serem escritos no mesmo idioma do aplicativo em teste.
Pilha de tecnologia de teste
Vamos
dar uma olhada no procedimento de teste usando o aplicativo da web
TodoMVC como um
exemplo na
implementação do AngularJS . O AngularJS é uma estrutura popular para a criação de aplicativos de página única (SPA).
Como AngularJS é JavaScript, usaremos
Cumcumber.js , ligação de pepino ao JavaScript.
Para emular o trabalho do usuário em um navegador, usaremos o
Selenium . O Selenium é um processo que pode iniciar um navegador e reproduzir ações dos usuários em comandos recebidos por meio da API.
Por fim, usaremos o
Transferidor para levar em consideração as nuances da emulação de aplicativos SPA escritos no AngularJS. O transferidor cuidará da expectativa de que as visualizações na página sejam carregadas corretamente.
Portanto, nossa pilha de testes é a seguinte:
O processo apresentado neste diagrama é descrito da seguinte maneira:
- Quando o teste do pepino é executado, o pepino lê a definição de teste no arquivo Gherkin.
- Em seguida, começa a chamar o código de implementação do código de teste.
- O código de implementação do script de teste usa o transferidor para executar ações em uma página da Web
- Quando isso acontece, o Transferidor se conecta ao servidor Transferidor e emite comandos ao Selenium por meio da API.
- O Selenium executa esses comandos em uma instância do navegador.
- O navegador, se necessário, se conecta ao (s) servidor (es) da web. Em nosso exemplo, o aplicativo SPA é usado, portanto, essa conexão não ocorre, pois o aplicativo já foi carregado ao carregar do servidor da primeira página.
A implantação dessa pilha em uma infraestrutura não em contêiner não é fácil. E não apenas pelo grande número de processos e estruturas usados, mas também porque o lançamento de um navegador em um servidor sem monitor sempre foi difícil. Felizmente, em um mundo em contêiner, tudo isso pode ser automatizado.
Farm de Teste de Integração
Os aplicativos da Web corporativos precisam ser testados para várias combinações do SO e do navegador do cliente. Geralmente, isso é limitado a um determinado conjunto básico de opções que reflete a situação nas máquinas dos usuários finais do aplicativo. Mas, mesmo nesse caso, o número de configurações de teste para cada aplicativo raramente cai abaixo de meia dúzia.
Se você implantar consistentemente uma pilha para cada configuração de teste e executar os testes correspondentes nela, isso será muito caro em termos de tempo e recursos.
Idealmente, eu gostaria de executar testes em paralelo.
O Selenium-Grid pode nos ajudar com isso - uma solução que inclui o broker de solicitações do Selenium Hub e um ou mais nós nos quais essas solicitações são executadas.
Cada nó do Selenium que geralmente é executado em um servidor separado pode ser configurado para uma combinação específica de SO e navegador do cliente (no Selenium, essas e outras características do nó são chamadas de recursos). Ao mesmo tempo, o Selenium Hub é inteligente o suficiente para enviar solicitações que exigem determinadas propriedades do Selenium aos nós que possuem essas propriedades.
Os clusters de Selenium-Grid são bastante difíceis de instalar e gerenciar, e tanto que as empresas que oferecem serviços relacionados chegaram a aparecer no mercado. Em particular, SauceLabs e BrowserStack estão entre os principais players.
Teste de integração baseada em contêiner
Muitas vezes, eu gostaria de criar um cluster de Selenium-Grid que forneça as propriedades de Selenium necessárias para nossos testes e execute os próprios testes com um alto grau de paralelização. Depois que o teste estiver concluído, eu gostaria de poder destruir completamente esse cluster. Em outras palavras, para aprender a trabalhar da mesma maneira que os fornecedores de farms de teste de integração.
Essa área de tecnologia ainda está em um estágio inicial de formação; no entanto, um projeto promissor de código aberto - o
Zalenium - oferece parte do que precisamos.
O Zalenium usa um Hub modificado que pode criar nós sob demanda e destruí-los quando não forem mais necessários. Atualmente, o Zalenium suporta apenas navegadores Chrome e Firefox na plataforma Linux. Mas com o advento dos nós do Windows para o Kubernetes, o suporte ao Explorer e Edge no Windows pode aparecer.
Se você juntar tudo, a pilha tecnológica é a seguinte:
Cada oval no diagrama é um pod separado no Kubernetes. Os pods do testador e emuladores são efêmeros e destruídos no final do teste.
Executando testes de integração no pipeline de CI / CD
Vamos criar um pipeline simples no Jenkins para mostrar como integrar esse tipo de teste de integração ao restante do processo de gerenciamento de liberação. É assim:
Seu pipeline pode variar, mas você ainda tem a oportunidade de reutilizar a fase de teste de integração sem refatoração significativa de código.
Como a maioria das lareiras é efêmera, uma das tarefas do pipeline é coletar os resultados dos testes. No Jenkins, isso pode ser feito usando o arquivo morto e as primitivas publishHTML.
E este é um exemplo de um relatório sobre os resultados dos testes (observe que os testes foram executados em dois navegadores):
Conclusão
Portanto, apesar da complexidade de organizar uma infraestrutura de teste de integração de ponta a ponta, a abordagem "infraestrutura como código" simplifica o processo. A execução de testes de integração em várias combinações de SO e navegadores leva muito tempo e recursos, mas as ferramentas de orquestração de contêiner e as cargas de trabalho efêmeras ajudam a lidar com esse problema.
Mesmo na ausência de ferramentas maduras para organizar testes de integração orientados a contêineres, os testes de integração baseados em plataformas de contêineres já podem ser realizados hoje e tirar proveito da abordagem de contêiner.
Se você estiver desenvolvendo aplicativos em contêiner, tente usar essa abordagem no pipeline de CI / CD e veja se isso ajuda a simplificar os testes de integração.
O código de exemplo deste artigo pode ser encontrado no site do GitHub em redhat-cop / container-pipelinesh.