Primeiras aulas do curso React: automatizando os testes em aplicações front-end

React: automatizando os testes em aplicações front-end

Começando a escrever testes - Apresentação

Oi. Bem-vindo ao curso de teste com react. Vamos ver um pouco do que vamos ver nesse curso. Se você ainda não sabe o que é React, ainda não usou, dá uma olhada na lista de pré-requisitos aqui do curso, dá uma lida antes para você se familiarizar, porque vamos partir direto para a parte de testes. A parte de aplicação vai estar pronta, mas é bom que você entenda o que está sendo feito.

Temos uma aplicação, que é o ByteBank, é um internet banking, e com ele nossos usuários, nossos clientes podem fazer transações de saque ou depósito, por exemplo, vou fazer um depósito de 500 reais. Essa transação vai ser exibida numa lista com todas as transações que o usuário fez, tipo um extrato.

Aqui tenho meu extrato com todas as minhas transações, inclusive a que fiz agora, essa última. E tenho que garantir que isso esteja sempre funcionando para que meus clientes, independente do local, do horário em que tentem acessar o internet banking sempre consigam fazer a transação ou ver o saldo, ou a lista de transações que eles precisam.

Vamos agora para o nosso código. Já vamos receber pronto esse código para o nosso projeto e vamos adicionar os testes. Aqui temos a conta onde tenho o formulário para realizar a transação, também tenho meu saldo sendo exibido, tenho uma transação individual daquele feed de transações. Tenho minha lista de transações completa, que é esse componente de transações. E também tenho meu app, que vou ter o cálculo do saldo, as chamadas para a API, onde estou fazendo minhas transações de fato.

Esse é nosso componente principal da nossa aplicação. Para garantir que nossa aplicação esteja segura e que nossos usuários vão sempre conseguir fazer o que eles precisam vamos adicionar os testes e vamos adicionar teste de snapshot, teste de componente, vamos fazer mocks para simular o retorno das nossas APIs, vamos fazer mocks para funções.

Tudo isso vamos ver ao longo do curso usando React Testing Library. Essa é a cara do que vamos trabalhar nos próximos dias. Eu sou a Eduarda e vou ser a instrutora desse curso. Bora começar?

Começando a escrever testes - Criando o primeiro teste

O projeto que vamos usar no curso é um app de banco, o ByteBank, e você já vai receber ele pronto. Com ele posso fazer transações, por exemplo, posso fazer um depósito, também posso fazer um saque, e com isso vou ter também minha lista de transações. Aqui tem as duas que fiz agora e também um histórico de transações na minha conta, e posso ver meu saldo. Meu saldo foi mudando à medida que fui fazendo transações.

Como é um app de banco é esperado que o dinheiro que as pessoas coloquem lá vai estar seguro, então que sempre que eu abrir minha conta meu saldo exibido vai ser de fato o saldo que eu tenho, que minhas transações sejam corretas, que não tenha transação a mais, transação a menos.

Para isso é importante que garantamos que tudo esteja funcionando, mesmo que adicionemos coisas novas nesse internet banking. Para isso vamos usar o React Testing Library, que é uma lib de testes para react, e vamos usar ele para construir testes automatizados, para que quando eu faça alguma alteração no código não precise ficar fazendo esses testes manuais que fiz agora para saber se saque ou depósito está funcionando.

Começamos no app, que é o principal componente dessa transação, então é onde vou carregar, por exemplo, a conta e as transações, que são aquelas duas partes visuais que vimos antes, e também as principais funções, como por exemplo as chamadas de API.

Agora indo para o código, temos o app.js, que é o principal componente da nossa aplicação, e aqui é onde é carregada a conta e as transações, que são aquelas duas partes visuais que vimos antes no app funcionando. Também tenho as chamadas de API e as principais funções do nosso internet banking.

Para adicionar o teste vamos criar um novo arquivo, vai ser o app.test.js, o nome app é para identificar que estamos fazendo um teste daquele arquivo teste e o test é uma convenção, então pode ser que você também encontre algum projeto como app.expect.js.

Para o nosso teste vamos precisar de uma estrutura para ele funcionar. Preciso descrever o que é meu teste, então describe(‘Componente principal’, () =>, dentro dele vou ter casos de teste. Agora quero saber se, por exemplo, o nome da minha aplicação está sempre aparecendo, porque quero que meus clientes sempre saibam que eles estão no app do meu banco.

Vou ter um caso de teste. Para isso posso usar o it, e também vou descrever o que é esse it, o que ele está fazendo. Aqui é mostrar o nome do banco. Aqui dentro é onde vou criar o teste de fato. O que eu quero é que meu nome do banco sempre esteja visível para os clientes.

Para isso vou usar o expect. Estou esperando alguma coisa que seja outra, nesse caso quero que o nome do meu banco sempre esteja no documento html. Como o código é em inglês, temos a função toBeInTheDocument, que significa saber se a coisa que estou esperando vai estar no documento html.

O que quero ver é o texto, então vamos ver se eu só passar o texto aqui, por exemplo, ByteBank, se vai funcionar esse teste. Agora podemos ver se vai funcionar. Se eu passar essa string esperando que ela esteja no meu documento, se meu teste vai achar.

Para isso, vamos salvar o arquivo e vou executar meus testes, então npm test. E meu teste falhou, porque preciso que tenha um elemento html para que ele consiga buscar, e não tenho aqui ainda. O elemento que estamos trabalhando é o app, para isso vou importar ele aqui, import App from ‘./app’, mas não posso só passar o app aqui dentro.

Eu preciso renderizar ele de alguma forma. Como é um componente react também preciso importar o react. Para renderizar esse componente, fazer ele ser exibido, para que o teste consiga achar o texto, eu vou usar uma função chamada render, do React Testing Library, que é a lib que vamos usar, e também vou precisar do screen para que meu teste consiga acessar esse componente que ele criou.

Vou importar o que vou precisar, e dentro do meu teste vou renderizar o meu componente app, e vou usar ele ao invés da string. Vou usar o screen para acessar esse componente. Preciso buscar o texto de alguma forma. Vou usar esse getByText, significa que estou buscando por um texto, e vou passar agora a string do meu texto, então ByteBank.

Essa parte do toBeInTheDocument continua porque quero saber se ele está no meu documento html. Meu teste passou agora, e para ter certeza de que estamos testando certo podemos quebrar mais uma vez. Vou procurar por ByteBanko, e não tenho.

Aqui conseguimos ver o que ele gerou no render. Isso tudo é o componente html e ele vai buscar aqui se tenho aquele string ByteBanko. Não tenho. E quando busco por ByteBank, ele acha, e por isso meu teste vai passar.

Vamos voltar para o código. Se tirarmos o o, o teste está pronto. Para ter certeza de que nosso teste está funcionando, podemos também fazer ele falhar propositalmente.

Vou procurar por ByteBanko. Meu teste vai falhar. Vamos ver o que acontece. O meu teste, aquele render gerou tudo isso. Precisamos disso porque estamos executando nosso teste no servidor, pelo terminal. Não temos a aplicação para o teste visualmente buscar se tenho o texto ou não. Aquele render vai gerar todo o html, por exemplo, do nosso componente, para que o teste consiga buscar o que estamos procurando.

Nesse caso, temos o ByteBank, não temos o ByteBanko, por isso ele quebrou, e se eu trocar o texto para ByteBank e vier nos testes ele vai passar.

Começando a escrever testes - Organizando o arquivo de teste

Aqui temos nosso primeiro teste do nosso componente app e tenho um describe e um it que está executando um teste só, mas por exemplo posso querer ter outros casos de teste para esse mesmo componente. Posso criar outro caso de teste it, o nome do meu teste, vamos ver se o saldo está sendo exibido agora, então mostrar saldo.

Aqui vou ter meu teste de fato. Preciso renderizar o app, que nem no meu primeiro teste, o meu componente, e quero que meu saldo esteja aparecendo, então tenho que buscar de alguma forma esse meu saldo. Se formos ver na aplicação, o saldo tem o texto “saldo:” antes de ter o valor de fato. Então podemos usar isso para fazer a busca.

Então, getByText(‘Saldo:’)).toBeInTheDocument, da mesma forma que fizemos antes. Vamos ver como ficou esse teste. Estou vendo que tenho o componente principal, mostrar o nome do banco, e tenho o teste mostrar saldo também sendo executado, mas ele não está dentro do mesmo escopo.

Colocamos o it fora do describe, isso é possível, o it é a única coisa obrigatória para você ter um arquivo de teste. Mas para organizar melhor temos o describe para criar blocos que fazem sentido no contexto. Tenho o cenário, que vai ser o componente principal, e vou ter casos de teste relacionados a esse cenário.

Por exemplo, tenho mostrar nome do banco e mostrar saldo, o importante é que tenhamos nomes que façam mais sentido, então podemos escrever melhor o que é o mostrar o nome do banco. Por exemplo, quando eu abro o app do banco, o nome é exibido.

Aqui tenho muito mais claro qual é essa funcionalidade que estou querendo garantir que esteja funcionando. Como o mostrar saldo faz parte do mesmo contexto, podemos passar ele também dentro do mesmo describe, quando abro o app do banco, o saldo é exibido. Agora eles vão estar no mesmo contexto.

Quando executamos os testes, vemos que eles estão fazendo parte desse mesmo bloco. Vou adicionar mais um teste, que pode ser, por exemplo, saber se o botão de transação está sendo exibido na página, que é bem importante conseguir fazer a transação.

Quando abro o app do banco, o botão de realizar transação é exibido. Da mesma forma que os outros vou renderizar o app, que é o componente que estou testando, e vou ter que pegar de alguma forma esse botão para saber se ele está na página, vou usar o screen.getByText, vamos ver agora qual texto posso usar para achar no botão.

Posso usar o nome dele, realizar a transação, texto de exibição dele, e toBeInTheDocument, assim como os outros. Nosso teste falhou, vamos ver por que isso aconteceu. Subindo, vamos ver o componente renderizado. Temos todo o html dele, e em cima ele diz para nós o que aconteceu. Tenho uma mensagem de erro.

No meu componente principal, meu teste, quando abro o app do banco, o botão realizar transação é exibido está vermelho, significa que falhou. E a mensagem de erro do teste está falando que ele não conseguiu achar o texto no meu componente. Então vamos ver como está o texto dele no componente de fato.

Tenho meu botão e o nome dele, o texto dele é realizar operação. No meu teste, coloquei realizar transação, ele não achou o botão e o teste falhou. Se mudarmos para realizar operação, salvar, o meu teste vai passar.

Se formos ver agora nossos testes, temos o describe, que criamos o componente principal, e em todos os meus casos de teste estou repetindo essa frase quando abro o app do banco. Isso acaba ficando bem repetitivo. Imagine que temos vários cenários de teste. Isso pode acabar poluindo nosso terminal, fica mais difícil de ler, fica mais difícil de identificar o que está sendo testado de fato.

Para isso podemos melhorar um pouco essa organização com outro describe. Vamos voltar para o nosso teste. Posso adicionar outro describe dentro do describe que tenho. Vou adicionar o describe quando abro o app do banco, que é o cenário específico que estou querendo testar agora.

Aqui dentro vão ter todos os casos de teste desse meu cenário específico. Vamos mover tudo lá para dentro. Agora, quando abro o app do banco descrito no describe posso apagar tudo isso dos meus testes. Vai ficar bem mais simples. E vamos ver como ficou.

Os meus testes já estão rodando automaticamente porque estamos no modo oti. Toda vez que faço a atualização e salvo o documento, os meus testes também são executados novamente.

Tenho meu componente principal do primeiro describe, tenho quando abro o app do banco, que é esse meu primeiro caso específico, primeiro cenário específico que vou ter mais de um caso, e depois tenho todos os meus testes iniciais. Posso fazer, por exemplo, quando abro o app do banco, o nome é exibido. Quando abro o app do banco, o saldo é exibido, e quando abro o app do botão o botão de realizar transação é exibido.

Mas no teste ficou de forma muito mais enxuta e muito mais fácil de vermos o que teve algum problema e o que está sendo testado. E assim conseguimos documentar melhor nosso código. Uma pessoa que não está no projeto, começou a trabalhar recentemente, quando ele exibe os testes, isso vai contando uma história das features que tem naquele arquivo. É mais fácil de acompanhar o que está acontecendo.

No meu arquivo de teste temos dois tipos de funções diferentes. Temos o describe, que vai ter o primeiro parâmetro, que é o nome da minha função, é o que estou descrevendo desse bloco de código, e uma função, que é o que ele vai executar. Dentro dele posso ter mais describes e posso ter os its.

Os its também podemos escrever como teste. É a mesma coisa, vai ser executado da mesma forma. Dentro dele também vou usar dois parâmetros agora, que é o nome dele, a descrição desse meu caso de teste, e também uma função, que é o que o teste vai executar de fato.

Tenho meu render, tenho o que estou esperando que meu teste faça. Se formos ver no teste sendo executado, vamos ver que o test e o it são usados da mesma forma. Não muda a forma que estou lendo o meu resultado do teste.

Sobre o curso React: automatizando os testes em aplicações front-end

O curso React: automatizando os testes em aplicações front-end possui 90 minutos de vídeos, em um total de 40 atividades. Gostou? Conheça nossos outros cursos de React em Front-end, ou leia nossos artigos de Front-end.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

Aprenda React acessando integralmente esse e outros cursos, comece hoje!

Plus

  • Acesso a TODOS os cursos da plataforma

    Mais de 1200 cursos completamente atualizados, com novos lançamentos todas as semanas, em Programação, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.

  • Alura Challenges

    Desafios temáticos para você turbinar seu portfólio. Você aprende na prática, com exercícios e projetos que simulam o dia a dia profissional.

  • Alura Cases

    Webséries exclusivas com discussões avançadas sobre arquitetura de sistemas com profissionais de grandes corporações e startups.

  • Certificado

    Emitimos certificados para atestar que você finalizou nossos cursos e formações.

  • Alura Língua (incluindo curso Inglês para Devs)

    Estude a língua inglesa com um curso 100% focado em tecnologia e expanda seus horizontes profissionais.

12X
R$85
à vista R$1.020
Matricule-se

Pro

  • Acesso a TODOS os cursos da plataforma

    Mais de 1200 cursos completamente atualizados, com novos lançamentos todas as semanas, em Programação, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.

  • Alura Challenges

    Desafios temáticos para você turbinar seu portfólio. Você aprende na prática, com exercícios e projetos que simulam o dia a dia profissional.

  • Alura Cases

    Webséries exclusivas com discussões avançadas sobre arquitetura de sistemas com profissionais de grandes corporações e startups.

  • Certificado

    Emitimos certificados para atestar que você finalizou nossos cursos e formações.

  • Alura Língua (incluindo curso Inglês para Devs)

    Estude a língua inglesa com um curso 100% focado em tecnologia e expanda seus horizontes profissionais.

12X
R$120
à vista R$1.440
Matricule-se
Conheça os Planos para Empresas

Acesso completo
durante 1 ano

Estude 24h/dia
onde e quando quiser

Novos cursos
todas as semanas