Talking About TestingATT</>
Testes de Unidade com Jest

Acerte 100% do quiz para continuar

Aula
Prévia gratuita

O seu primeiro teste de unidade

Escreva um teste com describe, test e expect, execute-o e aprenda a ler uma falha.

Um teste de unidade verifica um pedaço pequeno de código, uma unidade, isoladamente: normalmente uma função, chamada com alguma entrada, com o resultado comparado ao que uma regra diz que ele deveria ser. Sem navegador, sem servidor, sem banco de dados. É por isso que testes de unidade rodam em milissegundos, e por isso que um teste que falha aponta direto para o que quebrou.

Nesta aula, você escreve o seu primeiro teste de unidade, para a função lateFee(), e aprende as três coisas de que todo teste do Jest é feito: um grupo, um teste e uma expectativa.

Visão geral dos comandos 📖

require() do código sob teste

Um arquivo de teste é JavaScript comum. Ele começa fazendo o require da função que testa.

Sintaxe:

const { functionName } = require('./module-file')

Exemplo:

const { lateFee } = require('./fees')
👨‍🏫 Você nunca faz o require do próprio Jest. Quando o Jest executa um arquivo de teste, ele deixa describe, test, expect e o resto disponíveis como globais.

describe()

Agrupa testes relacionados sob um nome. Grupos podem ser aninhados, e os nomes se somam na saída.

Sintaxe:

describe('<o que está sendo testado>', () => {
  // os testes vão aqui
})

Exemplo:

describe('lateFee', () => {
  // os testes da função lateFee() vão aqui
})

test() (ou it())

Define um teste: um nome e uma função que o executa. it é um apelido de test, então it('charges...') e test('charges...') são a mesma coisa. Este curso usa test.

Sintaxe:

test('<o comportamento, como uma frase>', () => {
  // chame o código e verifique o resultado
})

Exemplo:

test('charges 25 cents for each day late', () => {
  expect(lateFee(10)).toBe(250)
})
👨‍🏫 Dê ao teste o nome do comportamento que ele verifica, e não o nome da função. "charges 25 cents for each day late" diz o que quebrou quando ele falha. "lateFee works" não diz nada.

expect() e toBe()

expect(value) embrulha o valor que você obteve, e um matcher o compara com o valor que você esperava. toBe() é o matcher mais simples: ele passa quando os dois são o mesmo valor (ele usa Object.is, que é a igualdade estrita, ===, para números e strings).

Sintaxe:

expect(<recebido>).toBe(<esperado>)

Exemplo:

expect(lateFee(0)).toBe(0)

Executando um arquivo, ou todos

Sintaxe:

npm test
npx jest <caminho-do-arquivo-de-teste>

Exemplo:

npx jest src/fees.test.js

Modo watch

--watch mantém o Jest rodando e reexecuta os testes relacionados aos arquivos que você altera, toda vez que você salva. Enquanto ele roda, pressione a para executar todos os testes, f para executar só os que falharam, p para filtrar pelo nome do arquivo, t para filtrar pelo nome do teste e q para sair.

Sintaxe:

npx jest --watch

Exemplo:

npm test -- --watch
👨‍🏫 O --watch depende do git para saber quais arquivos mudaram, e é por isso que ele funciona no seu clone sem nenhuma configuração. O -- em npm test -- --watch diz ao npm para repassar a flag ao Jest em vez de ficar com ela.

Lendo uma falha

Um teste que você nunca viu falhar pode não estar verificando nada. Então a primeira coisa a aprender é como se lê uma falha. Suponha um teste que espera 200 onde a regra diz 250:

 FAIL  src/fees.test.js
  lateFee
    ✕ charges 25 cents for each day late (3 ms)

  ● lateFee › charges 25 cents for each day late

    expect(received).toBe(expected) // Object.is equality

    Expected: 200
    Received: 250

      5 |
      6 |   test('charges 25 cents for each day late', () => {
    > 7 |     expect(lateFee(10)).toBe(200)
        |                         ^
      8 |   })

Leia de cima para baixo:

  • FAIL e o nome do arquivo: qual arquivo tem um teste falhando.
  • lateFee › charges 25 cents for each day late: o nome do describe e o nome do test, juntos. Bons nomes fazem desta linha uma frase.
  • Expected e Received: o que o teste queria, e o que o código retornou.
  • O trecho de código: a linha exata da asserção que falhou, com um acento circunflexo embaixo do matcher.

E então decida quem está errado. Aqui, o README diz 25 centavos por dia, então 10 dias dão 250, e quem está errado é o teste. Mais adiante no curso, vai ser o contrário.

Conteúdo sugerido 📚 e links da documentação 🔗

Exercício 🎯

Crie o arquivo src/fees.test.js. Dentro de um bloco describe('lateFee'), escreva testes para estas regras do README, usando valores bem dentro de cada faixa:

  • Um livro devolvido no prazo (0 dias de atraso) não tem multa.
  • Um livro com 10 dias de atraso custa 250 centavos (25 centavos por dia de atraso).
  • Um livro com 20 dias de atraso custa 500 centavos.

Execute npm test e veja os três passarem. Depois quebre um de propósito: mude o valor esperado do teste de 10 dias para 200, execute de novo e leia a falha de cima para baixo, como descrito acima. Volte para 250.

Por fim, inicie o modo watch com npm test -- --watch, altere e salve o arquivo de teste algumas vezes e veja os testes rodarem sozinhos de novo. Pressione q para sair.

👨‍🏫 Faça o commit do novo arquivo de teste e o push.

Mostre ao mundo o que você aprendeu 🌎

Para mostrar à sua rede profissional o que você aprendeu nesta aula, publique o seguinte no LinkedIn.

Estou fazendo o curso "Testes de Unidade com Jest" com @Walmyr Lima e Silva Filho na @Talking About Testing School, e acabei de escrever os meus primeiros testes de unidade com o Jest, vi um falhar de propósito e aprendi a ler os valores esperado e recebido e o trecho de código de uma falha. #TalkingAboutTesting #TATSchool #UnitTestingWithJest #Jest #UnitTesting

👨‍🏫 Lembre-se de me marcar na sua publicação. Aqui está o meu perfil no LinkedIn.

Quiz

Pergunta 1 de 2
Pontuação: 0

Um teste falha com Expected: 200 e Received: 250 para lateFee(10). O que você deveria fazer antes de mudar qualquer coisa?

Acerte 100% do quiz para continuar