Unstubbed network requests in specs come in all sort of issues:
- specs failing unpredictably due to connectivity issues
- significantly slower test suites
- hitting API rate limits on 3rd party services
So running specs in isolation should always be high in your priority list.
Many developers to solve this issue use VCR to record live interaction and “replay” it back in specs. I used it as well in a couple of projects with somewhat limited success.
Cons that I found in VCR:
- specs become a bit noisy with unrelated terminology of cassette handling
- specs doesn’t clearly represent system under test because the most important info is hidden in recorded cassettes which are not in your actual spec files.
- changing the written response body in recorded VCR cassette manually is not always easy and itself is an anti-pattern in VCR approach.
Webmock allows us to operate on a lower level and gives us ability to update output more easily(and keep specs clean and concise). But before stubbing network request you need to know the exact default response by third-party service that you need to replicate in your specs.
mitmproxy to the rescue!
Here’s the solution that I tried in several projects that worked great for me:
mitmproxy is a free and open source interactive Man-in-the-middle HTTPS proxy.
You run your spec with the following system ENV variables:
http_proxy=http://0.0.0.0:8080 https_proxy=http://0.0.0.0:8080 so it forwards your network requests through mitmproxy running in debug mode.
All unstubbed requests would be displayed in logs like so:
Just copy that response JSON and add it to your Webmock stub_request configuration.