Testando na web: TestCafé, automatizando seus testes
Atualmente é uma perca de tempo ficar falando sobre a importância da construção de testes em qualquer tipo de sistema, pois existem dezenas de artigos que já mencionaram isso e é seu dever saber sobre. Então vamos pular essa parte, que em resumo diz: para evitar ter bugs nos seus sonhos noturnos, faça testes!
É fato! Existem diferentes tipos de testes, o que pode deixar qualquer iniciante perdido sem saber para qual lado da bagaça ir. Mas calma lá, temos a pirâmide de Cohn para nos ajudar:
A imagem do tio Martin Fowler já explica tudo, quanto mais perto do usuário mais caro e lento é o teste, tendo como topo o teste de interface, ou os famosos testes e2e (end-to-end).
Advinha com qual testes iremos trabalhar nesse artigo? 😁 😂
É isso aí mesmo que você deve ter pensado, vamos trabalhar com o teste de interface, ou melhor, teste e2e. Mas peraí, porque fazer isso? Ele não é o mais lento e mais caro da pirâmide?
Sim, é sim! E daí? 😴 💤 … Apesar da pirâmide ser uma técnica bastante concreta, foi mencionada pela primeira vez em 2009, atualmente quem dizer que esse tipo de teste leva muito tempo e dinheiro está falando balela.
Hoje em dia temos diversas ferramentas (geralmente feitas em Node.js, então caso não tenha instalado, instale-o para usar) com o intuito de solucionar esse problema (Cypress, Protactor, Codecept, Nightwatch, …), neste artigo iremos usar o TestCafé, o motivo para isso é a minha própria vontade 🤗 !
… Mas para aqueles que querem motivos técnicos, aqui vão alguns: sintaxe amigável; fácil instalação e uso; não tem a necessidade de usar webdriver; suporte a execução em dispositivos remotos; plataforma online (💲) para gravação e execução dos testes;
Agora chega de ladainha, vamos colocar pra ferver ♨️!
Vamos criar um projetinho para armazenar nosso código, então crie um diretório em algum lugar da sua máquina e dentro dele execute o comando npm init -y, com ele estamos criando o arquivo package.json no projeto para gerenciar as suas dependências.
Nesse caso vamos ter apenas a dependência do TestCafé, pois não vamos ter o código do sistema (dado que podemos testar a interface de qualquer sistema), então executamos o comando npm install testcafe@alpha -D no terminal.
Perceba que estamos usando a flag D para salvar essa dependência na área de desenvolvimento do npm, pois iremos usa-lo apenas na fase de desenvolvimento. Além disso, pedimos o npm para instalar a versão alpha do framework, pois na versão estável existe um bug que atrapalharia o seguimento do artigo (evidências)👻.
Depois de instalar, crie um diretório tests no projeto, nele iremos colocar o código dos testes. Nesse diretório crie o arquivo google.test.js, nele iremos fazer um teste que pesquisa pelo Training Center no Google e validar o resultado:
Antes da explicação do código, note que usamos seletores CSS para capturar os elementos de DOM do sistema, para captura-los em sistemas de terceiros use o inspecionador do navegador. Caso tenha alguma dúvida de como usa-lo deixe um comentário pedindo um artigo só sobre o assunto.
Na linha 3 do código foi colocado o nome do recurso a ser testado (fixture) e a página onde aquele recurso está disponível (page), abaixo nós temos nosso teste com um nome e um método, nesse método executamos as ações que o caso de teste determina, como:
- typeText: digita um texto no elemento do seletor informado. No caso, digita no campo de busca do Google.
- click: clica no elemento do seletor informado. No caso, primeiro clica na logo da Google para tirar o dropdown de sugestões de busca, e por último clica no botão para pesquisar.
- expect: informa que estamos esperando um resultado. No caso o Selector da lista de resultados, onde buscamos por h3.r e pegamos a primeira ocorrência do mesmo (nth), ou seja, o título do primeiro resultado retornado pelo Google.
- eql: compara um expect com o valor informado. No caso compara se o título do resultado é igual a string informada.
Agora podemos executar o comando testcafe chrome tests para executar todos os scripts de testes (por isso informei a pasta tests) no navegador da Google.
Você pode usar o comando testcafe -b para visualizar a lista de navegadores disponíveis para o seu computador.
Após isso, o navegador será aberto automaticamente com a logo do TestCafé, o caso de teste será executado e você verá ele digitando a pesquisa, coletando o resultado e dando uma mensagem de sucesso no terminal, algo parecido com esse exemplo oficial:
No mundo real isso ainda não é o suficiente, seus clientes irão querer provas que o sistema está funcionando e sendo testado automaticamente, para isso o TestCafé disponibiliza o método takeScreenshot(), que como o próprio nome diz tira um print da tela. Assim podemos salvar todo o passo a passo do processo feito no teste para comprovar junto ao cliente a execução completa do fluxo.
Para tirar evidência de cada passo, vamos literalmente colocar o armazenamento de print em todo lugar, deixando nosso código assim:
Precisamos fazer uma pequena alteração no comando para poder executar o teste, agora temos que informar em qual pasta ele irá salvar os prints do teste, para isso usamos a flag s, deixando-o assim: testcafe chrome tests -s output
Dá para perceber que nosso comando está ficando cada vez maior, então para evitar desenvolvedores desinformados podemos adiciona-lo ao script test do package.json, deixando-o assim:
Veja que fui um pouco intruso e coloquei algumas coisas a mais no comando, adicionei o firefox na lista de navegadores, assim ele irá executar os testes no Google Chrome e também no Mozilla Firefox ao mesmo tempo. E por fim adicionei a flag — selector-timeout para informar que o tempo limite para ele encontrar os elementos da página será de um minuto, caso não haja o elemento na tela depois desse tempo o teste irá quebrar. Isso é útil quando seu cliente determina um tempo máximo de resposta do sistema.
Agora você poderá executar os testes com o comando npm run test, a partir disso o nosso teste será executado no Firefox e no Chrome, após isso será finalizado com sucesso e os prints ficarão expostos em um diretório dentro de output.
Com isso é dado o fim desse artigo, nele vimos que os testes de interface estão cada vez mais simples de serem criados. Na minha opinião é possível ver algumas vantagens em seu uso, com ele você estará testando o lado do cliente, que é o que realmente importará do seu sistema no fim.
Em suas desvantagens está a fragilidade do código do teste, pois caso qualquer desenvolvedor altere o seletor de um elemento usado em testes, o teste decorrente irá quebrar. Além de NÃO tirar a necessidade de um teste unitário.
Por fim gostaria do seu feedback sobre esse artigo e assunto, caso tenha dúvidas, críticas ou sugestões deixe nos comentários. Caso queria mais artigos relacionados, dê um feedback e uma palmada também 🤗 👏👏.
