D4no0
Http client e2e testing
I have a project where we do http requests to public domains.
I am currently using Mox for testing and following their practices by having a callback for the http client and a implementation:
defmodule HttpClient do
@callback request(atom(), binary(), binary(), keyword(), keyword()) ::
{:ok, HttpClient.Response.t() | HttpClient.MaybeRedirect.t()}
| {:error, any()}
end
While it works great for tests with mocked data, I still find that these tests are double edged, as they are fully dependent on the correctness of data and format of it, we already had cases where the tests would pass and the application would fail at runtime.
I was wondering if maybe replacing this kind of mocked tests with a real local http server (similarly to how ecto uses sandbox) that exhibits real properties would be better and make for cleaner and easier to manage tests.
Any thoughts on this or tools you could recommend?
Marked As Solved
hst337
I would recommend Patch for everybody. It is universal and more friendly solution.
This is caused by different data in tests and in reality. You can just copy-paste data from real responses and use it on testing. Or you can even use solutions like ExVCR
Anyway, final decision depends on amount of time you have and what quality of tests you want
Also Liked
hst337
- Cassettes can contain outdated data: some services have TTLs for their responses. Or something like your ID in the third-party service can change and responses in cassettes can become stale. A lot of other stuff too
- They’re not easy to rerecord correctly. Because manual changes to the cassettes have to be reapplied every time you rerecord them
dimitarvp
I get it that it might not be scalable to manually collect all of the API responses but I have used ExVCR in the past and ended up… manually collecting all the API responses that I needed for tests. The API had slight changes – 3 times in a single year – but it was enough to piss us off because we shipped non-working features in production due to outdated cassettes.
So we rolled up our sleeves and what do you know, something like 70 API responses took 3 people 5-6 work days (and we were not doing only that, it was just an ongoing effort). Not a huge deal, though granted it’s annoying to do.
So I am with @hst337 here – take control of this.
Of course nobody is stopping you scripting this somewhat. I was able to devise a small text file format a while ago (next time I needed something like this) and just have a bash/zsh script loop over the lines inside the file and do curl requests and record the responses. Took me 80% the way there (though it was super specific and was not generalizable).
hst337
Beware: VCR solutions are hard to maintain
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"