[FEATURE] Testes - Com foco em auxiliar a migração do Strapi V3 para o Strapi V4 e atualizações futuras.

Essa Issue é uma continuação mais elaborada e focada pra Frontend desta outra Issue, elaborada para sugerir os testes do nosso BE

[Sua solicitação está relacionada a um problema? Por favor, descreva.]

Olá pessoal! Gostaria de sugerir a implementação de testes unitários e de integração no FrontEnd para auxiliar, principalmente, na atualização do Strapi V3 para V4. Além disso, gostaria de indicar alguns pontos relevantes para aproveitarmos este momento de atualização do backend. No futuro, poderemos desenvolver testes de Ponta a Ponta (E2E), conforme possível, para garantir o funcionamento completo e desejado da plataforma. Abaixo, apresento mais detalhes e soluções específicas para cada caso.

[Descreva a solução que você gostaria]

Testes Unitários: Para componentes que dependem, principalmente, de rotas do backend Strapi, como cards de Ameciclistas, Projetos, Grupos, Login, entre outros.

O intuito inicial seria mapear tudo no site que utiliza nossas rotas do Strapi e fazer testes que verifiquem a existência desses componentes. Assim, quando houver qualquer atualização no sistema, poderemos identificar diretamente o que está quebrando para ser corrigido/adaptado. Por exemplo, a estrutura de resposta das rotas do Strapi mudou bastante do V3 para V4, como observado neste PR. Testes que identifiquem partes do site que utilizam essas estruturas guiariam nossas adaptações manuais necessárias de código. Sugiro utilizarmos o React Testing Library pela resiliência da biblioteca e uso intuitivo para nossos testes unitários com React.

Testes de Integração: Focando no acoplamento dos endpoints do backend para todas as páginas gerenciadas pelo CMS Strapi.

Aqui, testaríamos basicamente se o Strapi, em conjunto com o Next.js, está fornecendo corretamente nossas informações e montando tudo corretamente. Isso evitaria, por exemplo, que conteúdos personalizados para cada tipo de usuário apareçam para o público anônimo visitante do site, como a página Grupos, que deve aparecer apenas para associados. Sugiro usar o Jest + Supertest, que oferecem soluções bastante poderosas e completas para integração, ou o Testing Library, que já é unificado e acompanha um planejamento de escalada do site conforme formos lidando com mais componentes que se relacionam entre si. Acho que essa última opção pode ser mais completa pensando em escala, apesar de Jest com Supertest serem mais familiares para a maioria dos programadores. Aqui, seria importante sentarmos e elaborarmos melhor a solução mais coerente com o nosso momento e como pensamos em trabalhar no futuro.

Testes de Ponta a Ponta (E2E): Para simular um ambiente o mais próximo possível da experiência do usuário no cliente (navegador).

Assim, podemos entender com mais clareza detalhes que os testes anteriores podem não enxergar por estarem dentro de um ambiente mais controlado e analítico do que uma simulação real. Aqui, podemos usar e desenvolver o que já está sendo feito através do fluxo CI do projeto com Cypress. Hoje, nossos testes Cypress testam apenas uma pequena parte da página home, o banner. A intenção é que ele cubra tudo que seja possível clicar e navegar no site, permitindo execução local simulando um cliente popularmente utilizado como uma janela do Chrome. Isso facilita qualquer plano de correção de código antes de enviar para o nosso fluxo CI/CD em nuvem, poupando tempo e trabalho no futuro e deixando a aplicação muito mais segura e previsível. Além disso, os testes E2E servem como uma documentação poderosa da nossa aplicação para desenvolvedores que queiram entender, contribuir e participar dos nossos projetos open source no futuro.

Contexto adicional

Com isso, já dá para ter uma dimensão de como os testes podem ajudar o site da Ameciclo, não só limitando-se a ele, mas a qualquer aplicação que seja de um projeto da Ameciclo. Os testes podem dar mais segurança e norte para criarmos nossas plataformas, tendo mais confiança de que, se tivermos imprevistos, saberemos onde agir com rapidez. É importante lembrar que os testes não vão beneficiar apenas a nossa migração atual de Strapi V3 para V4, mas servirão para todos os ciclos de vida da aplicação, podendo ser espelhados e utilizados por várias outras organizações semelhantes como um mapa para a criação de suas aplicações através do modelo de Desenvolvimento Orientado a Testes (Test-Driven Development - TDD).

Espero ter contribuído e agradeço o espaço de colaboração! Vamos discutir essa ideia? O que vocês acham?

Ameciclo / ameciclo