VCR vs ExUnit Tags

I’ve used both and would do so again. I’ve worked with complex multi-step API’s, where the tests were also acting as documentation for what the API accepted and returned and that the app was setup correctly to make them. In that situation, something like ExVCR is a godsend. It is possible to get stale cassettes, but it can still be useful to know that you didn’t introduce a regression with a known valid response. In most cases, I’d prefer using Mox, but that is explicitly not testing your integration with the API. So, you need to be sure you’re ok with that. Mox has the advantage that you can use async: true, whereas most other things that do mocking use meck and thus mock globally. It’s also much easier to use Mox on code you own. If you’ve build a client that wraps an API you own, it’s probably going to be pretty easy. If it’s someone else’s, it’s probably going to be much harder.

I just reread that article, it’s worth mentioning, it’s primarily talking about things that use your API client and having them not make the HTTP calls. However, if you want to test the client, you need to make the HTTP calls. It’s just suggesting that you do those things separately.

If you use behavior based mock, then you assume the client library behaves that way, and test your logic around the client library.

If you use exvcr, you test the behavior of the client library.

So it depends what you actually want to test.

Just saw this as well: https://moosecode.nl/blog/introducing_walkman

I haven’t used it, but it uses a similar method to Mox in overriding so that async works.

I believe VCR is an interesting tool in some scenarios and we need think
about its usage case by case.

I already had scenarios where we depended on several legacy internal APIs, for
example and the QA/test environment of these APIs where not reliable. In cases
like these I believe VCR brings a great value because it allows us to run
the tests isolated from the stability/instability of the QA/test environment
(that were out of our control, depending on other teams, etc).

Using tags, by default the tests are not executed and to execute them we
mandatorily depends on the environment. Using VCR this is optional, we can trust
that changing the API is an exception (not the rule) and we are able to run the
test really hitting the API or not.

In this case, during the development process we generally uses the VCR, because
the API probably was not changed between the first and the second running, but we
can run without it when we desire (during the development or in a CI, for
example).

So, given these benefits and flexibility (that have a big weight to me) I like so much this approach in these scenarios.