Engineering

Simulando erros de rede com proxy: entenda como reproduzir erros complexos

Felipe Simões

Simulando erros de rede com proxy: entenda como reproduzir erros complexos

Não seja atormentado com erros de rede em produção difíceis de reproduzir, conheça o Charles Proxy e saiba como ele facilita sua vida.

02 setembro

TEMPO DE LEITURA: 3 minutos

destaque

Imagina a cena: um alerta do rastreador de erros surge de uma ferramenta de monitoramento ou até um chefe atento: “O usuário não consegue acessar uma tela do sistema”, “O cliente está recebendo uma mensagem de erro”, “Todo dia um ou dois usuários são deslogados do sistema inesperadamente”. 

Então, o time de desenvolvimento parte para investigar a causa raiz e começa a andar em círculos, ninguém consegue sequer reproduzir o problema. Depois de muito tempo e cabeça quente, alguém enfim consegue falar com o cliente e descobre que sua internet de casa é na verdade bem lenta e instável. De repente tudo parece fazer mais sentido. Agora, a questão passa a ser, como simular a experiência do cliente do lado de cá?

Todo sistema está sujeito às condições da rede

No dia a dia de quem trabalha com desenvolvimento de software para internet, nos deparamos com um erro ou outro que aparece em ambiente de produção e passou despercebido durante os testes. Tanto a pessoa desenvolvedora como aquelas que ajudam a validar a entrega podem não considerar certos cenários de falha, e eventualmente surge um cliente alertando que teve uma ingrata surpresa ao usar o sistema. 

O ponto é, um sistema que roda e depende de rede está sujeito a uma grande gama de condições como latência, banda, perda de pacote, cache, entre outras. Obviamente, nem sempre é razoável testar essas condições devido ao esforço para conseguir reproduzi-las de forma fidedigna.

Mas e então, o que fazer? Nada? Torcer pra que isso não aconteça? E se acontecer e precisarmos corrigir, como garantir que foi realmente corrigido? A gente liga pro cliente e pede pra tentar de novo. Será que tem uma forma de simular esses comportamentos?

Claro que tem! A ideia aqui é te ajudar nisso. 🙂

Simulando as condições de rede usando um proxy

Uma forma bastante útil de simularmos condições de rede é usarmos um proxy. Que podemos entender como uma caixa de comunicação entre sua conexão local e a internet. Essa caixa pode ter várias ferramentas interessantes que simulam como a internet responderia para sua conexão local. Dessa forma nós conseguimos simular falha de conexão, lentidão, perda de dados, e até respostas específicas do servidor.

Pense no seguinte cenário: você está desenvolvendo uma aplicação web que consome uma API. Dependendo do retorno do status code e body da resposta do serviço você formata a exibição do frontend. Enquanto desenvolve você facilmente testa o retorno ideal da API com código 200 e uma resposta formatada com dados. Prevendo uma possível falha no servidor você trata o status 500, exibindo uma mensagem amigável de “por favor, tente recarregar a página”. 

Tudo parece bem, até que sua feature vai para produção e começam a ser reportados erros pelos usuários. Inspecionando a fundo você descobre que sua aplicação não trata o retorno de código 401. Você até sabe que um usuário logado por muito tempo pode ter seu login expirado, mas de alguma forma a aplicação não forçou o usuário a refazer seu login. Tudo seria mais fácil de testar se você pudesse forçar o retorno da API exatamente como acontece para seus usuários.

A sugestão aqui é usar o Charles Proxy, um intermediário entre seu tráfego de rede e as aplicações que executam na sua máquina. Com ele você consegue inspecionar as requisições disparadas pelas aplicações locais e também o retorno dos servidores. Mais do que isso, você é capaz de interceptar essas requisições, e substituir respostas para endereços de rede conforme for mais interessante para seu caso.

Um exemplo de feature muito útil é a “Rewrite”. Através dela você pode definir regras de respostas simuladas de acordo com a verdadeira resposta do servidor. A exemplo: caso a API retorna 200, repassa um erro 401 para aplicação local (como no cenário citado antes).

Fonte: Interna – Coruja Labs

Diferente de usar um servidor mockando respostas, perceba que aqui você pode usar a comunicação com o servidor real, mas forçar cenários em ambiente controlado que são úteis para desenvolvimento e testes. Outro exemplo interessante de situação simulada é forçar um retorno específico no corpo da resposta. Aqui a API que só retorna URLs de imagens de cães decide que só tem imagens de gato.

Legenda: Exemplo de uma request interceptada com resposta modificada.

Uma ferramenta como essa possibilita também, que você simule conexões lentas em diferentes velocidades. Assim como permite que você habilite intermitência nas requisições de um determinado domínio. Deste modo, é possível observar como sua aplicação se comporta diante de lentidão ou falhas ao carregar certas requisições. Pode ser que um endpoint específico do qual sua aplicação dependa esteja tornando a experiência de navegação muito ruim e, talvez, até travando o carregamento de toda a página.

Existem muitos possíveis caminhos e comportamentos que sua aplicação pode apresentar de acordo com condições de rede e respostas nem sempre previsíveis de outras aplicações da qual ela depende. O uso de um proxy pode ser muito útil desde reproduzir problemas específicos dos usuários, a prevenir esses erros e tornar sua aplicação mais resiliente a diferentes cenários. 

Então seja você uma pessoa desenvolvedora ou que trabalha com testes de software, fica a recomendação para conhecer esse tipo de ferramenta e explorar possíveis comportamentos do software com o qual trabalha. Tome a iniciativa e force esses erros a aparecerem antes que eles estejam diante do seu usuário final.

https://www.charlesproxy.com/

author do post

Engineering, Proxy

«

»

VOCÊ TAMBÉM PODE GOSTAR

Vagas Recentes

Confira todas as oportunidades no nosso Linkedin.