When I was working at Shopify, we did an overhaul to do this for every external call. I was dissatisfied with the mocks and had a hunch it was covering up about as many bugs as it was surfacing.
I wrote the first version of Toxiproxy, which sits between your application and service, and then you can write tests like this:
Toxiproxy[/redis/].down do
Shop.first # this will throw an exception
end
I recommend going to this extent instead of monkey-patching if you find yourself doing that a lot.
We found many bugs in Rails, especially in the connection handling logic, that the mocks did not uncover for us. Some were very serious, but all were fixed upstream many years ago.
When I was working at Shopify, we did an overhaul to do this for every external call. I was dissatisfied with the mocks and had a hunch it was covering up about as many bugs as it was surfacing.
I wrote the first version of Toxiproxy, which sits between your application and service, and then you can write tests like this:
I recommend going to this extent instead of monkey-patching if you find yourself doing that a lot.
We found many bugs in Rails, especially in the connection handling logic, that the mocks did not uncover for us. Some were very serious, but all were fixed upstream many years ago.
This is very interesting, thanks for the link!
I don’t think the trade-off is worth it for us at PostHog yet, but glad to know this exists for the future.
A former colleague of mine wrote this, don’t know if that could help here: https://github.com/meshy/django-sans-db.
I was curious to see how this works, and as it turns out, it uses the exact same code as in the ‘greatest option 3’ in the post :)