Um Pull Request dispara vários eventos, não um só
Um bot de review, uma automação de merge, ou um pipeline de CI reagem a mais de um evento ao longo da vida de um PR: opened, depois cada synchronize (novo commit), e por fim closed (com merged: true ou false). Testar só o payload de abertura deixa boa parte da lógica sem cobertura. Veja a referência de endpoints do GitHub pra um payload isolado.
Modelando com Response Sequences
// Mock Rule: POST / → Response Sequences, mode: last
[
{ "status": 200, "body": "{\"action\":\"opened\",\"number\":42,\"pull_request\":{\"state\":\"open\",\"merged\":false}}" },
{ "status": 200, "body": "{\"action\":\"synchronize\",\"number\":42,\"pull_request\":{\"state\":\"open\",\"merged\":false}}" },
{ "status": 200, "body": "{\"action\":\"closed\",\"number\":42,\"pull_request\":{\"state\":\"closed\",\"merged\":true}}" }
]Cada chamada sucessiva ao endpoint devolve o próximo evento — sua automação recebe exatamente a sequência opened → synchronize → closed que aconteceria num PR real, sem precisar abrir e mergear um PR de teste no GitHub toda vez.
E a assinatura X-Hub-Signature-256?
Mesma limitação honesta do artigo do Stripe: o motor de templates do httpdrop não gera HMAC — o header
X-Hub-Signature-256 não sai criptograficamente válido do mock. Teste a verificação de assinatura separadamente (o GitHub disponibiliza ferramentas próprias pra isso, como reenviar deliveries reais pelo painel de Webhooks do repositório). O que o httpdrop testa bem é a lógica que reage a cada action do payload.Próximo passo: combine com mocks em pipeline de CI/CD pra rodar esses cenários automaticamente a cada build.