6 etapas para refatorar um caso de teste do Jest

Um recurso pouco conhecido do Jest é a possibilidade de personalizar como os erros de asserção exibidos no console são tratados quando os testes falham. Imagine o seguinte código de teste, que precisa percorrer um objeto programaticamente para garantir que as chaves existam como esperado (usando a função expect):

O teste está bem escrito. Agora, imagine o que acontece se alguém da equipe fizer algumas alterações no código: adicionar um novo arquivo em uma parte e esquecer de incluí-lo em outra parte importante do mesmo projeto, como garantir que ele seja exportado corretamente.

Na próxima vez que o teste for executado, ele vai falhar. No entanto, o motivo não será óbvio para a maioria das pessoas; e, se você não conhece o código, provavelmente nem vai saber o que deu errado. Experimente:

Por isso, o Jest também exige o uso de toHaveProperty() com expect, assim:

Agora, quando um teste falha, fica pelo menos mais claro qual propriedade está faltando. No entanto, ainda é um pouco enigmático, como você pode ver na próxima captura de tela. O que podemos fazer? ?

Neste ponto, as anotações que já estão lá talvez sejam suficientes. O nome do teste é autoexplicativo, como você pode ver. Mas temos apenas um caso de teste que falha e, ao analisar o rastreamento do teste, não conseguimos avaliar com clareza quais validadores foram usados.

Vamos refatorar o código:

Agora, quando meu teste passa ou falha, fica muito mais claro e intuitivo entender exatamente o que foi testado, o que falhou e por quê:

Muito melhor! ???

Se você gosta do Jest tanto quanto eu (?), talvez também tenha interesse em ler alguns dos meus outros artigos sobre Jest:

• Desmistificando padrões de testes assíncronos com Jest

• Motivos para amar o Jest: a experiência do desenvolvedor

• Motivos para amar o Jest: o framework de testes

Se você também se interessa por segurança na web, adoraria encontrar você na comunidade do Slack do The Secure Developer ou no Twitter, se preferir.