A Pull Request fires several events, not one
A review bot, a merge automation, or a CI pipeline react to more than one event over a PR's lifetime: opened, then each synchronize (new commit), and finally closed (with merged: true or false). Testing just the opening payload leaves much of that logic uncovered. See the GitHub endpoint reference for a single isolated payload.
Modeling with 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}}" }
]What about the X-Hub-Signature-256 header?
Same honest limitation as the Stripe article: httpdrop's template engine doesn't generate HMAC — the
X-Hub-Signature-256 header won't come out cryptographically valid from the mock. Test signature verification separately (GitHub provides its own tools for this, like redelivering real webhook deliveries from the repo's Webhooks settings). What httpdrop tests well is the logic that reacts to each payload action.Next step: combine with mocks in a CI/CD pipeline to run these scenarios automatically on every build.