Migrando do Enzyme pro React Testing Library

Bom, primeiro preciso falar pra vocês que faz um ano que me aventurei nesse mundo de testes. Eu nunca tinha escrito um e, apesar da curiosidade, só consegui aprender mesmo quando entrei pra um time que tem esse hábito dentro da cultura de engenharia.

O time que eu entrei escrevia os testes em Enzyme e me habituei facilmente a fazer o mesmo com a ajuda dos desenvolvedores mais experientes. Mas chegou um momento, depois de resolver alguns débitos técnicos que resolvemos migrar de um framework para outro. Mas… Por que migrar? Vou falar três motivos que nos fizeram migrar.

Menos valores “chumbados”, comportamentos mais reais

No Enzyme, quando testamos o componente, usamos o state e as props do mesmo. Isso geralmente significa que os testes são meio frágeis, sabe? Por exemplo, quando escrevemos o teste de um input com Enzyme e precisamos de uma interação nele com modificação de valor, geralmente usamos o change e colocamos entre parênteses um valor que é aplicado a ele de maneira não orgânica. Já no RTL(React Testing Library), seria como um algoritmo mesmo, uma sequência de ações bem próxima ou igual a interação do usuário, ao digitar ou escolher outro valor pro input citado.

Não precisar ficar dando 'update' no Wrapper o tempo todo

Em muitas situações precisávamos forçar update no wrapper que criávamos para renderização do componente e, em muitos casos, isso acontece automaticamente no RTL.

Escrever casos de teste mais similares a ação do usuário

O RTL nos incentiva a escrever melhores componentes, seguir acessibilidade e HTML semântico, devido a hierarquia e boas práticas de uso dos seletores.

Uma mudança de mentalidade

Durante a migração, eu passei por uns desafios, por estar acostumada a selecionar os componentes pelo id e ter que passar a selecionar por roles em sua grande maioria. Como dito nos Guidelines Principles, o teste deve se parecer com a forma como os usuários interagem com seu código (componente, página, etc.) tanto quanto possível. Com isso em mente, eles recomendam uma ordem de prioridade para o uso dos seletores. Mas não se preocupe! Temos vários facilitadores para conseguirmos frisar isso na nossa cabeça, como por exemplo o que eu uso: o Testing Playground. O bacana em concentrar-se em testar o comportamento dos usuários em vez da implementação é que permite refatorar facilmente o código em momentos futuros.

Futuras melhorias

Além do que citei acima sobre facilitar refatorações, o RTL instiga você a escrever componentes acessíveis e são inúmeros os ganhos que seu produto ou aplicação vão ter com isso.

Conclusão

Pelo que usei do Enzyme nesses meses, acho que ainda é uma biblioteca muito poderosa para testar seu aplicativo e tem grandes desenvolvedores que mantêm a comunidade bem ativa. Mas usar constantemente nesses dois últimos meses o RTL me fez ver e criar componentes com mais facilidade e fluência, seguindo ainda boas práticas de acessibilidade, além de escrever testes mais estáveis que nos permitem testar o comportamento vs. implementação. Ou seja, estou amando!

Obs: Nenhuma ferramenta é objetivamente melhor do que a outra, ok? Você deve considerar qual ferramenta é melhor pro seu time e projeto ao tomar uma decisão sobre qual ferramenta usar. Temos limitações no Enzyme e também existem limitações para o RTL -como não ser capaz de acessar o state do componente (o que pode ser intencional porque você não deveria estar fazendo isso em teoria 👀).

Essa foi a nossa experiência no meu squad! Gostou? Passou por algo similar? Conta pra mim!