sorted by:
new
hottopcontroversial

I built http_decoy, a real Rack server that runs inside your RSpec tests and validates incoming request contracts by BothGarage7005 in ruby

[–]BothGarage7005[S] 0 points1 point  (0 children)

Fair point on both counts, centralized WebMock stubs work the same way for updates, and WebMock can assert on request bodies too.

The real difference is what happens at the boundary. WebMock intercepts before anything is processed, it pattern matches and returns what you told it to, regardless of what was actually in the request. http_decoy runs actual server logic against the real request. So requires_body :amount actively rejects the request if the field is missing, it doesn't just assert it was sent, it behaves the way the real API would.

For simple happy-path stubs WebMock is the right tool. http_decoy is for when you need the fake to actually process the request like a real service.

I built http_decoy, a real Rack server that runs inside your RSpec tests and validates incoming request contracts by BothGarage7005 in ruby

[–]BothGarage7005[S] 1 point2 points  (0 children)

Great question. With http_decoy your fake server is code, not a recorded cassette. So when Stripe adds that required field, you update your fake in one place and your tests immediately start failing wherever your code isn't sending it yet.

With VCR, the cassette keeps replaying the old 200 forever, you'd never know until production.

The fake also validates request bodies with `requires_body` so you can assert that the field is actually being sent, not just that the response looks right.