Testes no front-end, quando? E como?

[wilsongomes-swe]

Fala galera,

estamos estruturando uma política de testes em nosso front aqui na empresa, e gostaria de opiniões baseadas na prática sobre qual a melhor maneira de fazer este fluxo e estabelecer um fluxo padrão?
(Front com ReactJS equipe com 5 pessoas, projetando ir para 10 pessoas em 5 mêses)

• Testes unitários são uma boa no front? Quando?

• Testes de integração e end-to-end?

• CyPress é o maisn indicado para testes de funcionalidades da UI?

• Jest, Enzyme, Super Teste?

O que usam e como fazem a parte de testes no front?

Muito obrigado, abraços!

[lddv]

Bom dia, Wilson.

Entendo testes como uma garantia dentro daquilo que é mais crítico para o seu negócio. Uma rede de proteção enquanto o seu sistema se equilibra na corda bamba. Assim como um equilibrista, existem certos movimentos que são mais difíceis - ou fluxos que são mais perigosos e propensos a erros.

Dessa forma, não acredito em uma fórmula mágica mas certas diretrizes como testes unitários e testes de integração para fluxos complexos são uma boa pedida. Se o seu layout está consolidado, snapshot testing pode te ajudar, mas na minha experiência eles mudam muito rápido e você acaba tendo que lidar com o fato de o teste ser mais um usuário a ser satisfeito no seu fluxo de desenvolvimento. Ficar atualizando esses testes a cada mudança é quase uma redundância ao controle de versão do git, não é mesmo?

Uma ótima fonte para entender mais são blogs do Kent C. Dodds e os posts do Eric Elliot, ambos em inglês. Mas deixo uma tradução que achei do primeiro post aqui.

Respondendo às suas perguntas:

1. Testes unitários são uma boa quando o seu fluxo é mais complexo do que apenas mostrar HTML e CSS na tela. Transformações e outras manipulações de JS podem ser extraídas em funções, que por sua vez podem ser testadas em blocos únicos - unit test.

2. Válido, porém é necessário ter em mente que o custo de configuração e adequação da infraestrutura pode ser mais elevado, principalmente considerando que os testes podem ser feitos em um ambiente automatizado, usando headless browsers.

3. Cypress é um ótimo candidato, mas não se esqueça de outras ferramentas clássicas como Nightwatch.js, WebDriver.io, entre outros.

4. Desenvolvo em React, por isso utilizo Jest por já vir por padrão e acredito que ele é uma excelente combinação de ferramentas já consolidadas como Jasmine e Istanbul. Comecei a ir na onda do Enzyme e ainda acredito que possa ser usado quando fizer sentido, mas pessoalmente prefiro seguir a filosofia dos testes serem mais fiéis à experiência do usuário. Portanto, considero importante evitar testes que verifiquem sua execução linha a linha, e utilize mais a abordagem de configurar, acionar e verificar.

Infelizmente a maioria das minhas referências estão em inglês, mas espero que seja útil para esclarecer alguns pontos.

Um abraço.

[reynaldobarrosjr]

Um centavo de contribuição no como...você já conhece o https://github.com/garris/BackstopJS ? Ele testa as telas fazendo diff entre arquivos de modelo e o implementado. Faz o teste em diferentes view ports também. Vale a pena conhecer.

[wilsongomes-swe]

Show galera, muito obrigado pelas opiniões e contribuições!

[AlyoshaS]

Olá, @wilsonneto-dev, tudo bem?

A resposta do @lddv é muito completa!
Mesmo assim gostaria de deixar meus 5 centavos:

Uma coisa que aprendi com o @renatorib é o mais importante é testar a rota do dinheiro, o que realmente traz valor para o projeto, um exemplo simples seria um signin. Esse seria o mínimo e mais importante. E não adianta você cobertura de 100% se os testes não são eficazes.

Tenho certo carinho com o Cypress, mas o custo dele é bem alto. Um exemplo é se no deploy da aplicação isso sempre será executado, os deploys demorarão mais tempo e isso precisa ser analisado com muita calma. Depende e é bom ter isso bem alinhado com o time. Ele também é bem pesado pra rodar localmente, então é bom que todos trabalhem em uma máquina boa.

Além do jest, recomento você dar uma olhada no react-testing-library.

[eliseumds]

Usamos uma solução custom com Puppeteer pra fazer E2E, mas custou muita grana/tempo pra implementar e acho que não valeu a pena porque ninguém quer atualizar os testes agora, afinal, o feedback loop é muito lento. No backend há uma mistura de tudo, dependendo da importância da feature sendo testada.

[yuritoledo]

Hoje trabalho 90% desenvolvendo o front-end em TDD e recomendo muito.
Utilizo testing-library com jest.

Com o testing-library testamos o resultado do código, ou seja, a UI e não a implementação do código, como faziamos anteriormente com enzyme.

De fato, essa é a melhor abordagem até o momento para testes no front: Testar o que seu usuário vê, interage, percebe.
Acaba sendo a mesma abordagem do Cypress, dependendo a forma que você escreve os testes - guiados por comportamento - , só que é infinitamente mais rápido - afinal é rodado no terminal, sem interface - e se usar com TDD, vai garantir uma cobertura até mais legal de testes.

[wilsongomes-swe]

Show @yuritoledo, com o jest vc chega a fazer testes unitários também? Ou apenas os end-to-end com testing-library?
Valeeu! Ajudará bastante a opinião.

[yuritoledo]

Na verdade o conjunto testing-library + jest é o que você usa para testes unitários (o componente sozinho, com suas lógicas) e os de integração (um componente com outro, normalmente em uma tela ou um componente com uma requisição da API, mockada)

End-to-end é cypress, onde você "vê" um "robozinho" clicando e inserindo dados no sistema e tals

[wilsongomes-swe]

Entendi, pensei que este testing-library era um cypress mesmo, entendi.... Aqui temos o cypress que nós devs fazemos muitos testes, e os que o pessoal de QA faz, mas sentimos faltas de testes na lógina de maneira mais micro. Valeeu!

[yuritoledo]

Então o testing-library é exatamente o que precisa ;)