como testar seus aplicativos da Web

na indústria de software, todos testam seus aplicativos de alguma forma. Muitas equipes de desenvolvedores têm esquemas de teste elaborados que são bem integrados com seus pipelines de integração contínua, mas mesmo aqueles que não têm testes automáticos ainda precisam encontrar maneiras de verificar se seu código funciona como pretendido.

construir um site e clicar nele manualmente com a ajuda de um navegador é uma variedade de testes. Embora não seja o mais sofisticado, ainda conta. O mesmo vale para ativar o cURL no console e enviar uma solicitação sintética para o endpoint da API que você acabou de criar.

este post discutirá como automatizar os testes manuais que já fazemos antes de mergulhar em diferentes tipos e metodologias de teste.

automatizando testes

os testes manuais são suficientes para aplicativos pequenos, mas, quando esses aplicativos crescem, sua superfície testável cresce com eles, causando dois problemas.

um, quando as pessoas precisam realizar testes toda vez que uma nova versão de um aplicativo é concluída, inconsistências podem surgir. Isso é especialmente verdadeiro se houver muitos testes. Dois, a pessoa que faz os testes não pode executar outras tarefas. Com aplicativos grandes, o teste pode levar vários dias.

A maneira mais lógica de resolver esses dois problemas é automatizar essas tarefas manuais. Existem dois tipos principais de testes para aplicativos da web: testes de interface do Usuário e testes de API. Duas ferramentas podem automatizá-las.

testes de IU

testes de IU podem ser realizados com uma ferramenta chamada Puppeteer. Puppeteer permite automatizar um teste de interface do usuário manual usando JavaScript. Ele é instalado via NPM com o seguinte comando:

 $ npm i puppeteer

você pode então escrever um script que controla uma versão sem cabeça do Chrome para executar seus testes. Este script pode se parecer com o seguinte:

(async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto('https://google.com', {waitUntil: 'networkidle2'}); const heading = await page.$('h1'); await browser.close(); if(!heading) console.log('No heading found!');})();

neste script, estamos iniciando uma instância sem cabeça do Chrome, navegando para example.com, e procurando um elemento h1. Se não existir, uma mensagem de erro será registrada.

testes de API

testes de API podem ser automatizados via carteiro. O Postman vem com uma interface gráfica para criar solicitações HTTP que podem ser salvas. Essas solicitações podem ser executadas mais tarde com apenas um clique do mouse.

para começar, baixe e instale a interface do usuário do carteiro. Os seguintes passos são necessários para criar e salvar um pedido:

1. Clique em Criar uma Coleção à esquerda
2. Inserir em Minha Coleção como o nome da coleção de
3. Clique em Criar
4. Clique nas reticências (…) da Minha Coleção na esquerda
5. Selecione Adicionar Pedido
6. Introduza o Meu Pedido como pedido de nome
7. Clique em Salvar para Minha Coleção

O pedido mostra-se na barra lateral esquerda em seu recém-criado coleção.

se você selecioná-lo, você terá que entrar example.com como um URL e adicione um teste. Para adicionar um teste, clique em testes na barra de guias abaixo do campo de entrada URL.

uma área de texto na qual você pode escrever seu teste em JavaScript aparecerá. O seguinte é um exemplo de teste:

pm.test("Status code is 200", () => { pm.response.to.have.status(200);});

se você clicar em Salvar no canto superior direito da tela e enviar logo após, sua solicitação será enviada. O script de teste será executado para determinar se a resposta teve ou não o status 200.

tipos de testes

existem três tipos diferentes de testes. Compreendê-los permite que você escolha o tipo certo de teste para as várias partes de sua pilha de software.

testes unitários

testes unitários são o tipo mais simples de teste. Eles verificam a exatidão de pequenas partes do seu código. Um teste de unidade geralmente cobre uma chamada para uma função ou uma maneira de usar uma classe.

um teste de unidade é geralmente o primeiro “usuário” do seu código. Algumas metodologias de teste até exigem que você escreva o teste antes da implementação do Código real do aplicativo.

testes unitários podem ser usados no desenvolvimento de back-end e front-end. Algumas equipes de desenvolvimento usam testes de unidade para verificar a saída dom renderizada de pequenas partes de seu código, como formulários ou menus. No back-end, os testes de unidade são frequentemente usados para testar o código entre o Servidor HTTP e o banco de dados ou outras APIs.

três corredores de teste amplamente utilizados para testes unitários são:

‐ Jest—Jest é usado principalmente no desenvolvimento frontend porque vem com recursos exclusivos, como teste de instantâneo, que ajudam com problemas como regressões de interface do Usuário. Um tutorial de brincadeira pode ser encontrado aqui.

‐ AVA-AVA é favorecida no desenvolvimento de back-end porque é especializada na execução altamente paralela de testes. Um tutorial AVA pode ser encontrado aqui.

‐ PHPUnit-PHPUnit é uma estrutura popular para testes unitários em PHP. Um tutorial do PHPUnit pode ser encontrado aqui.

se um teste de unidade requer alguns recursos externos, como conexões de rede ou bancos de dados, então você provavelmente está escrevendo um teste de integração. Este tipo de teste é coberto a seguir.

testes de integração

do ponto de vista da implementação, os testes de integração parecem testes unitários. A diferença é que os testes de integração testam várias partes da pilha juntas. Por exemplo, eles podem testar se o cliente e o servidor falam ou não o mesmo protocolo ou, em uma arquitetura de microsserviços, se os serviços estão ou não funcionando corretamente juntos.As verificações que geralmente acabariam em vários testes de unidade independentes podem ser agregadas em um teste de integração que determina se tudo está funcionando bem juntos.

os testes de integração são usados no desenvolvimento de front-end e back-end. Às vezes, eles são usados para ver se as duas partes estão interagindo corretamente, mas também podem ser usados para determinar se diferentes módulos de uma parte estão trabalhando juntos conforme o planejado.

você pode usar os mesmos corredores de teste para testes de integração que você usou para testes de unidade. No entanto, o Postman, a ferramenta de interface do Usuário usada acima para automatizar testes manuais de API, também vem com uma ferramenta CLI chamada Newman que pode ser integrada ao seu pipeline de CI/CD.

Newman pode executar coleções de Carteiros exportados, permitindo que você crie solicitações e testes com a interface do usuário do Carteiro e executá-los mais tarde via CLI. Um tutorial do Newman pode ser encontrado aqui.

se um teste de integração requer interação com a IU, ele é chamado de UI Test—addressed next.

testes de IU

testes de IU são os testes mais sofisticados. Eles tentam emular o comportamento do usuário de forma automatizada para que os testadores não precisem clicar em todas as partes do aplicativo manualmente.Os testes de interface do usuário geralmente ajudam a capturar uma interação específica que levou a um erro para um usuário. Depois de capturado, ele pode ser reproduzido com um clique para corrigir o bug e evitar que ele volte em uma nova versão.

os corredores de teste Jest e AVA mencionados antes podem ser usados aqui, mas você geralmente precisará de uma biblioteca extra para facilitar a interação da interface do usuário por meio de um navegador. As duas bibliotecas principais atualmente em uso para este processo são:

‐ Puppeteer—Puppeteer é uma biblioteca JavaScript que vem com uma implementação sem cabeça do Chrome que permite executar testes de interface do Usuário programaticamente em segundo plano. Um tutorial de titereiro pode ser encontrado aqui.

‐ Selenium-Selenium é uma estrutura que permite o controle remoto de um navegador por meio de uma biblioteca chamada WebDriver. Um tutorial de selênio pode ser encontrado aqui.

existem mais tipos de testes do que os listados aqui. Outros podem ter objetivos diferentes; por exemplo, testes de carga tentam encontrar gargalos de desempenho. Lembre-se de que os testes descritos aqui às vezes recebem nomes diferentes. Os três tipos apresentados acima são os essenciais para implementar quando começar. Usar um deles é melhor do que não usar nenhum teste automatizado.

metodologias de teste

metodologias de teste são maneiras de pensar sobre testes. Os três descritos abaixo são os mais usados.

Test Driven Development(TDD)

TDD é a metodologia mais utilizada e a mais técnica. Ele recomenda que você escreva seus testes antes de escrever o código real que deseja testar. Como você precisa escrever um teste apenas para a parte do código que está implementando, o tipo de teste que você escreverá é um teste de unidade.

os testes unitários são bastante granulares, portanto, com o tempo, o uso dessa metodologia resulta no acúmulo de muitos testes. Essa realidade, combinada com o fato de que os praticantes iniciantes de TDD tendem a escrever testes triviais, pode levar à criação de uma pilha de testes inúteis. Para evitar isso, é crucial atualizar e limpar os testes quando a equipe estiver mais familiarizada com o TDD e com os testes em geral.

é importante executar os testes com frequência, não apenas em um pipeline de CI/CD, mas também localmente em sua máquina de desenvolvimento. Escreva um teste, execute-o, veja-o falhar, implemente o suficiente para fazer o teste passar e repita o processo.

para uma leitura mais aprofundada, confira a descrição do TDD da Agile Alliance.

Desenvolvimento Orientado a testes de aceitação (ATDD)

ATDD é uma modificação do TDD que se concentra mais em casos de negócios e menos na implementação técnica. Os tipos de teste usados nesta metodologia são principalmente testes de integração, porque, muitas vezes, várias partes do sistema precisam ser usadas em conjunto para resolver uma necessidade comercial.

como os testes são menos técnicos, também é aconselhável incluir pessoas não orientadas tecnicamente no processo de teste. Proprietários de produtos e clientes podem ajudar a definir os casos de negócios para que um desenvolvedor possa escrever um teste para eles. Se o teste não puder ser executado com sucesso, fica claro que mais funcionalidades precisam ser implementadas.

ATDD funciona em um nível de abstração diferente do TDD, então as duas metodologias podem ser usadas juntas.

para uma leitura mais aprofundada, confira a descrição do TDD da Agile Alliance.

behavior Driven Development (BDD)

BDD é uma mistura de TDD e ATDD, e seu objetivo é usar o melhor dos dois mundos para tornar todo o sistema mais estável. BDD tenta especificar um sistema com testes que ilustram seu uso.

como o ATDD, o BDD tenta capturar casos de negócios. No entanto, também requer que você questione esses casos de uso com os “5 Porquês” porque os “porquês” são uma parte ausente no ATDD. Claro, é melhor perguntar aos clientes o que eles querem, em vez de confiar apenas na entrada do desenvolvedor. Mas também é importante questionar as suposições de ambos os grupos.

BDD também é uma mistura de TDD e ATDD no sentido de níveis de abstração. O TDD apenas testa as pequenas partes do seu aplicativo e o ATDD apenas testa como essas partes funcionam juntas. O BDD exige que você aplique essa metodologia a todo o seu aplicativo e suas pequenas partes, tornando o BDD uma abordagem mais holística para testes.

para uma leitura mais aprofundada, confira a descrição do BDD da Agile Alliance.

conclusão

embora nenhum teste seja terrível, o teste manual é melhor e o teste automatizado é o melhor.

dependendo do tamanho do seu aplicativo, um teste manual pode impedir que membros da equipe de desenvolvimento trabalhem em outros projetos por dias ou mesmo semanas, custando tempo e dinheiro ao seu negócio. Além disso, a tarefa monótona de realizar as mesmas interações repetidamente pode levar a deslizamentos que muitas vezes se manifestam em bugs não capturados.

os computadores são muito bons em repetir a mesma tarefa repetidamente, por isso é uma boa ideia delegar testes a um script e liberar o tempo de seus desenvolvedores. Se esses testes forem integrados ao pipeline de CI/CD, os testes já escritos podem ser executados implicitamente quando um novo commit chega aos seus repositórios.

é uma boa ideia empregar uma metodologia de teste desde o início, porque, frequentemente, os grandes problemas ao começar são “o que” e “quando” para testar. Essas metodologias podem ajudar a esclarecer um processo que torna os testes de redação mais consistentes para todos os membros da equipe.