Guia completo de testes de webhooks

A maioria dos webhooks segue um estilo de comunicação fire-and-forget. Nesse tipo de comunicação, o provedor dispara a requisição do webhook uma vez e não se importa se ela foi consumida ou se retornou o status code adequado. Isso torna os webhooks um sistema de comunicação bastante delicado, já que os consumidores precisam garantir que estão sempre prontos para receber e processar as requisições sem erros.

Como pode não haver uma segunda chance de receber um webhook (e mesmo os sistemas de retry têm limites), o sistema de consumo precisa ser bem testado para conseguir processar as requisições sem erros.

Você também precisa testar os seus servidores para descobrir quanta carga eles suportam e como a performance do processamento de webhooks pode ser melhorada. Os testes permitem tomar as decisões certas para escalar a sua infraestrutura de acordo com a demanda dos seus webhooks.

Neste artigo, vamos ver diferentes tipos de teste que podem ser feitos para detectar e eliminar bugs no processamento de webhooks, escalar de forma adequada e melhorar a performance.

Este guia cobre o processo de teste — os tipos de teste que você deve rodar e como implementá-los. Se você procura uma comparação de ferramentas de teste de webhooks (Hookdeck CLI, ngrok, localtunnel etc.), veja o nosso guia sobre as melhores ferramentas de teste de webhooks para desenvolvimento local.

Especificamente para testes locais, a Hookdeck CLI oferece inspeção, replay e filtragem de eventos, indo além de um simples túnel — feita sob medida para workflows de desenvolvimento com webhooks.

Testes unitários de webhooks para erros de lógica

O que são testes unitários?

Os testes unitários ajudam a testar as menores unidades do seu código (ou seja, as suas funções, classes e módulos). Essas unidades são testadas de forma isolada. A maioria dos testes unitários consiste em fornecer uma entrada definida e verificar o comportamento do código em relação à saída esperada.

Suponha que o handler do seu endpoint de webhook tenha uma função que verifica um registro no banco de dados ou executa autenticação; você vai querer testar essa função em um teste unitário para garantir que ela se comporta como esperado.

Como executar testes unitários

Testes unitários são feitos com uma biblioteca de testes, um test runner e uma biblioteca de asserções. Muitas vezes, esses 3 componentes principais vêm agrupados em uma única biblioteca. As bibliotecas de teste são específicas de cada linguagem — por exemplo, o Jest é uma biblioteca completa para bases de código JavaScript, o PHPUnit é a biblioteca mais popular para PHP, e o Go já vem com uma biblioteca de testes embutida.

Os detalhes de como executar testes unitários em diferentes bases de código estão nas documentações das respectivas bibliotecas.

Alguns dos testes que você vai querer fazer em testes unitários são:

• Verificar se o resultado esperado é alcançado quando uma entrada é fornecida a uma função
• Verificar se os cálculos dentro de funções e métodos de classe estão corretos
• Verificar o comportamento das funções quando dados ou tipos de dado errados são fornecidos como entrada
• Verificar se as classes são instanciadas corretamente
• Verificar se funções que executam operações no banco de dados preservam a integridade dos dados da aplicação
• …e muitos outros.

Benefícios dos testes unitários em webhooks

• Garantem que erros de lógica sejam detectados e removidos do código
• Detectam erros e orientam o tratamento de erros quando o tipo errado de dado é fornecido
• Reduzem o tempo de depuração, porque você não precisa se preocupar com partes do código que já foram testadas a fundo

Testes funcionais dos workflows de webhooks

O teste funcional é o tipo de teste que ajuda a verificar o comportamento completo do seu código. Em resumo, ele testa a soma das partes. Suponha que você tenha um endpoint de webhook que recebe uma notificação de pagamento e emite um ingresso para o cliente. Esse endpoint provavelmente faria o seguinte:

• Verificar se o usuário existe no seu banco de dados
• Criar um registro de ingresso para o usuário no banco
• Enviar um e-mail informando ao usuário os detalhes do ingresso

Essa operação envolveria chamar várias funções (que presumimos já terem sido testadas nos seus testes unitários). Os testes funcionais ajudam a verificar se o seu endpoint executou todas essas operações com sucesso e se o efeito esperado — o registro do ingresso e o e-mail ao cliente — realmente aconteceu.

Testando o processamento do seu webhook

A primeira forma de testar funcionalmente o seu webhook é verificar a requisição e o processamento. Esse teste garante que o seu webhook chega ao destino certo e é processado como esperado. Para isso, você vai precisar de um endpoint HTTPS acessível publicamente como URL de webhook.

Obter essa URL para fins de teste não é trivial; no entanto, a ferramenta de teste da Hookdeck fornece uma URL de webhook para você testar e inspecionar o comportamento e os detalhes direto no navegador.

Executando testes funcionais em URLs de webhook

URLs de webhook são endpoints da API da sua aplicação. Testar uma URL de webhook exige uma configuração capaz de enviar requisições simuladas ao endpoint e verificar a saída em relação aos resultados esperados.

Assim como nos testes unitários, a forma de escrever testes funcionais na sua base de código e as bibliotecas necessárias dependem da linguagem ou framework que você usa. Por exemplo, o supertest é uma biblioteca Node.js que pode ser usada para testar APIs enviando requisições simuladas e verificando o resultado.

Se você quer um framework de teste de API que funcione com qualquer base de código, o conjunto de testes do Postman é altamente recomendado. O Postman tem uma suíte de testes automatizados padrão de mercado para rodar testes contra o seu endpoint de webhook, seja em desenvolvimento, staging ou produção.

No Postman, você pode usar o seu endpoint de webhook para montar coleções simulando diferentes cenários (sucesso, falha, dados inválidos etc.) e escrever testes para cada caso de uso.

Os testes do Postman podem ser executados localmente ou automatizados em um pipeline de CI/CD usando o utilitário de linha de comando do Postman (Newman), como mostrado abaixo:

Benefícios dos testes funcionais em webhooks

• Ajudam a testar o workflow envolvido no processamento de um webhook
• A idempotência de webhooks pode ser verificada com testes funcionais
• Verificações de integridade de dados podem ser feitas inspecionando o resultado do processamento
• É possível observar a verificação e o tratamento de erros em situações de falha
• Verificações de autenticação também podem ser testadas com testes funcionais
• …e muitos outros workflows e resultados esperados específicos da sua aplicação podem ser inspecionados em busca de erros.

Testes de carga em webhooks para resiliência

Teste de carga é a prática de submeter a sua aplicação à pressão do tráfego de rede para descobrir quantas requisições ela consegue processar em um dado período sem descartar nenhuma.

Testes de carga são essenciais para aplicações que precisam processar muitos webhooks, pois ajudam a tomar decisões informadas sobre como escalar a aplicação à medida que o tráfego cresce.

Como fazer teste de carga nos seus webhooks

Um dos utilitários mais usados para testes de carga é o Apache Benchmark (AB, para abreviar). O AB é um utilitário de linha de comando que permite disparar um número específico de requisições (centenas, milhares etc.) contra um endpoint de API.

Você pode especificar o número de requisições a serem disparadas, o nível de concorrência e também o payload.

O comando AB abaixo especifica que mil requisições devem ser disparadas contra o endpoint [https://myserver.com/webhook-processing](https://myserver.com/webhook-processing) usando um nível de concorrência de 20 e enviando dados de um arquivo data.json em formato JSON.

ab -n 1000 -c 20 -p data.json -T application/json -rk https://myserver.com/webhook-processing

Algumas das informações que o AB fornece depois de concluir as requisições incluem:

• Número total de requisições executadas por segundo
• Número total de requisições concluídas
• Número total de requisições com falha
• Tempo médio por requisição

Abaixo está um exemplo do relatório gerado ao rodar o AB contra um endpoint:

Todas essas informações são úteis para engenheiros que precisam escalar a sua infraestrutura de webhooks.

Se você quer uma ferramenta de teste de carga mais especializada, para cobrir mais casos de uso, dê uma olhada em K6, JMeter (também da Apache) e Gatling.

Benefícios dos testes de carga em webhooks

• Ajudam a determinar a capacidade do seu servidor
• Ajudam a definir as configurações de rate limiting
• No escalonamento horizontal, ajudam a decidir sobre adicionar mais servidores para lidar com o tráfego crescente
• Ajudam a determinar quando introduzir um componente de processamento assíncrono como filas de mensagens

Profiling de webhooks para melhorias de performance

Profiling é a prática de amostrar uma parte do seu código em busca de gargalos de performance. As tarefas executadas no código envolvem várias micro-operações que podem ser representadas por uma call stack. Quando se percebe uma queda de performance — por exemplo, operações lentas ou métricas altas de requisições por segundo —, é muito importante fazer profiling do código de processamento de webhooks em busca de gargalos.

Esses gargalos podem vir de funções de longa duração (funções criptográficas, funções de hash etc.) na call stack, deixando a operação do webhook lenta.

Como fazer profiling do código de webhooks

O profiling é feito com um profiler. Um profiler é uma ferramenta que mede como um trecho de código consome recursos do sistema em tempo de execução. Ele ajuda a encontrar gargalos de performance e a entender o comportamento do código.

Com o profiler ativo, você precisa executar o código para obter resultados. Por exemplo, você pode enviar uma série de requisições à URL do webhook enquanto o profiler observa e, depois, consolidar os resultados quando as requisições terminarem.

Os profilers costumam estar diretamente ligados a linguagens específicas, mas já existem alguns que suportam várias linguagens. O Node.js tem um profiler embutido que pode ser usado junto com o Apache Benchmark. Um exemplo de profiler multilinguagem é o Blackfire, que atualmente suporta Go, PHP e Python.

Os relatórios dos profilers mostram quanto dos seus recursos está sendo consumido e qual código da call stack está consumindo. Isso fornece dados sobre quais funções precisam ser otimizadas para melhorar a performance.

Um dos relatórios que os profilers podem gerar são os Flame graphs. Um Flame graph é uma visualização da call stack em forma de chama que usa densidade de cores para representar as "zonas quentes" de uso de CPU. Abaixo está um exemplo de Flame graph:

Cada barra horizontal representa uma operação na call stack; o comprimento da barra indica o tempo que o código leva para executar. Quanto mais longa a barra, mais tempo a execução leva, o que pode ser um bom indicador de onde é preciso melhorar a performance. A densidade das cores indica o quanto a operação é intensiva em CPU, outro sinal de onde a otimização é necessária.

Benefícios do profiling de performance de webhooks

• Ajuda a detectar onde estão os gargalos de performance
• Ajuda a tomar decisões melhores sobre como escalar o servidor verticalmente
• Indica quais operações síncronas podem se tornar assíncronas para melhorar a performance

Como a Hookdeck ajuda

Testar webhooks em todas as etapas (desenvolvimento local, staging, reprodução de produção) esbarra sempre nos mesmos atritos: URLs de túnel que mudam a cada sessão, provedores que você não consegue acionar sob demanda com facilidade e payloads de casos extremos que você não consegue reenviar sem recriar as condições que os produziram. Correlacionar logs entre o provedor, a sua infraestrutura e a sua aplicação é mais lento do que corrigir o bug de verdade, e reproduzir casos extremos localmente normalmente exige gerar de novo eventos reais que você não consegue reenviar facilmente.

O Event Gateway da Hookdeck rastreia cada webhook recebido de ponta a ponta: requisição, payload, headers e resposta. Ele torna cada entrega histórica pesquisável e reenviável com um clique, enquanto a Hookdeck CLI oferece uma URL permanente de desenvolvimento local que não muda entre sessões, e qualquer evento passado pode ser reenviado contra o seu servidor local sem envolver o provedor. Comece a usar a Hookdeck e pare de depurar webhooks às cegas.

Para conhecer ferramentas que facilitam os testes de webhooks na prática, veja a nossa comparação das melhores ferramentas de teste de webhooks.

Conclusão

Testar é uma prática de engenharia muito poderosa que ajuda a construir bases de código estáveis e a aumentar a confiabilidade. Mas entender os benefícios dos testes é a melhor forma de se convencer a incorporá-los ao seu fluxo de desenvolvimento. Neste artigo, vimos como testar os nossos webhooks para garantir confiabilidade e os vários benefícios que isso traz. Quando surgirem problemas, o nosso guia de troubleshooting e depuração de webhooks pode ajudar a identificar e resolver as causas.

Testar webhooks ajuda a construir webhooks altamente confiáveis e performáticos, o que traz mais confiança e menos bugs para corrigir.