Recentemente, desenvolvi o hábito de ler pelo menos dois artigos cada noite antes de dormir para refletir mais sobre minha carreira. Ontem, o Medium sugeriu um artigo de uma grande empresa. O artigo falava sobre como a equipe implementou sua própria ferramenta de testes end-to-end dentro do projeto. Isso me lembrou de uma fase na minha carreira em que todos discutiam que deveríamos desenvolver nossas próprias tecnologias. Naquela época, eu era jovem e tola, mas aprendi que, às vezes, grandes empresas de tecnologia preferem controlar quais tecnologias usar, e isso faz sentido para mim. Está tudo bem.

No entanto, criar uma ferramenta E2E não me parece fácil. Trabalhei muito com o Cypress quando estava envolvida na equipe de Design System, e sempre gostei desse método de ver o que está sendo renderizado na página (eu sou front-end ne) e o que estamos testando, incluindo comportamentos, etc. Mas não posso negar que não é uma tecnologia simples.

De qualquer forma, estava pensando em como isso poderia ser um ótimo ponto para incluir no seu currículo. Em uma entrevista, você pode ser perguntado: “Qual é um dos maiores feitos da sua carreira?” e você poderia responder: “Ah, não é grande coisa, talvez quando eu trabalhei na xxx e implementamos nossa própria ferramenta para testar aplicações end-to-end…”

Fiquei muito interessado naquele artigo e o li com grande entusiasmo. Era um ótimo texto onde o autor discutia os desafios que os motivaram a não usar o Cypress e o Playwright (eu nunca tinha ouvido falar deste último antes, mas parece bastante semelhante ao Cypress com base na descrição dele). Ele mencionou quatro pontos, mas vou escrever sobre um deles:

Dificuldade em fazer chamadas para um endpoint de API alternativo sem implementar regras personalizadas de reescrita da camada de rede.

No projeto que eu trabalho atualmente, lido apenas com testes unitários, mas passei algum tempo resolvendo problemas e lendo a documentação do Cypress. Eu era estagiária naquela época, então aprendi muito com isso e estou quase certa de que o Cypress pode lidar com esse problema!

Então, comentei sobre isso no artigo, e acho que isso pode não ser amplamente conhecido. Veja, não acho que essa grande empresa não tenha pesquisado isso antes de começar a criar sua própria biblioteca com uma perspectiva revolucionária sobre testes end-to-end, mas isso me motivou a escrever sobre esses problemas e fornecer alguns exemplos básicos de como abordá-los (embora eu realmente não acredite que isso seja útil para eles, apenas para conhecimento geral).

Então, vamos ao problema: “Dificuldade em fazer chamadas para um endpoint de API alternativo sem implementar regras personalizadas de reescrita da camada de rede.” Neste caso, é importante notar que eles não disseram que é impossível, apenas que é difícil.

1. Interceptors

Com este código, estou interceptando solicitações para o endpoint especificado. Isso me permite simular uma resposta dentro do teste. Usar a propriedade “body” fornece os dados simulados, tornando a propriedade “fixture” opcional. As fixtures são úteis quando você deseja simular várias respostas ou configurar regras complexas na camada de rede. As propriedades “delay” e “throttleKbps” permitem simular condições de rede, como latência e limitações de largura de banda. Essa abordagem permite testar diferentes cenários sem modificar o endpoint real e possibilita aplicar várias condições de rede.

2. Configurações de Ambiente

Ok, isso pode ser mais difícil dependendo do projeto em que você está trabalhando, mas se você tiver essa opção, pode configurar diferentes ambientes para os testes e usar um arquivo .env para apontar as APIs para esses ambientes alternativos. Trabalhei em um repositório que tinha cinco ambientes, e um deles era dedicado exclusivamente a testes end-to-end. Essa configuração depende das necessidades e da robustez do seu projeto.

3. API Mockings

Talvez o ponto mais importante desta lista (embora eu realmente goste do primeiro) seja que você pode usar uma variedade de mocks de API para simular quaisquer respostas que desejar, sem precisar interagir com os endpoints reais. Existem inúmeras bibliotecas de mocking disponíveis; eu já usei a jackfranklin/test-data-bot, que não é a melhor, mas é uma opção para criar mocks baseados em respostas.

Novamente, estou quase certa de que essa grande empresa pesquisou essas soluções antes de afirmar que são difíceis e incompatíveis com seus problemas. No entanto, se você encontrar dificuldades ao fazer requisições para um endpoint de API alternativo porque acha que precisa implementar regras personalizadas na sua camada de rede, você pode usar interceptadores para simular respostas nos testes, redirecionar e manipular suas requisições de maneira simples. Você também pode usar configurações de ambiente para configurar diferentes ambientes, facilitando os testes em vários contextos. Além disso, você pode usar mocking de API, com ou sem uma biblioteca, para eliminar a necessidade de reescrever sua camada de rede!

Em alguns dias, escreverei mais sobre os outros pontos deste artigo…

Até mais!