Approach for numerous edge cases, HTTP GET, exvcr

Was just reading this article, might be helpful for you: https://medium.com/flatiron-labs/rolling-your-own-mock-server-for-testing-in-elixir-2cdb5ccdd1a0

Interesting but too heavyweight for my tastes.

That article actually re-convinced me to use mock and not to roll my own mock server.

I have already used all of them: exvcr, mock, mox and bypass. For testing code that relies on underlying HTTP client libraries I liked mock the most with bypass a close second.

mox is amazing for a lot of testing but it doesn’t help me mock the underlying HTTP client library. I’ll use mox when I write higher level code that tests working with my API client itself e.g. I will make it return {:error, :too_many_retries} and see if the higher-level code reacts properly to that.

exvcr I tried to use just today but it was too opaque for me and even though the docs / GitHub page are rich on details I was unable to achieve a simple scenario – namely have two use_cassette blocks one inside the other (as I was testing pagination and wanted two different requests mocked, and yes I used its query parameter distinction parameter). Plus it wasn’t obvious how to use recorded (custom) cassettes. I simply gave up after 10 minutes and reached for mock which took the same amount of time and worked right away with zero surprises (NOTE: I only used mock twice before and the last time was more than a year ago).

Not to incline future readers too much in any particular direction as libraries evolve and get better (though some don’t) but so far mock was the best for testing code that relies on a lower level library (by mocking the said lower-level library seamlessly) and mox for testing everything in your own code where you have full control.

Folks should really give patch v0.16.0 — Documentation try(also see the cheatsheet)
The ergonomics and guarantees you get with Patch are far better than Mock or Mox in many cases. There is a comparison if you want to know how each mocking library behaves under different scenarios

I am liking exvcr a lot now. For error cases, I started with stubs, but I am going to switch to a combination of stubs and recorded cassettes with shorten timeouts in the code under test.

Once you get in direct call, delete, and record workflow, it gets pretty efficient doing happy path tests with exvcr. The only thing that can be tricky is remembering to not use random data generation when creating input data, so that your requests match fixed data in cassettes. (I wish there was a way to specify only generating new random data when exvcr is recording new cassettes.)

Workflow:

• Edit code under test
• Comment out use_cassette calls
• Adjust tests and confirm updates work with live calls
• Delete cassette, enable use_cassette again
• Run tests triggering recording of new cassettes for deleted cassettes

Well I still have no clue how to pre-record cassettes so there’s that.

You can use one cassette and record multiple requests in that cassette.

For custom cassettes, you just specify the location to the custom cassette. It’s usually easier to record a cassette and then modify it into a custom cassette.

Maybe I can’t talk properly but again, I seriously don’t know what to do to record a cassette EXPLICITLY – not implicitly by running a test and allowing ExVCR to store it, not that – so I can reuse it later with the custom cassettes path.

Can you give me a working example?

The workflow I am interested in:

1. Run $mysterious_command to record an HTTP response
2. Store file under custom/cassettes/path
3. Specify the above path in my tests

I don’t know how to do #1.

You select an adapter from the exvcr tutorial. Then add the appropriate setup to an exunit test for your adapter. Then wrap your call in “use_casette” with your desired cassette name. Then run the test once. After the test has run, you will find the recorded cassette in your cassettes directory.

When I am at my computer tomorrow, I will try to detail out every step above with code snippets. We use hackney/httpoison at work, in case you are using a different adapter which may have issues that I am unaware of.

For the explicit case, there is an iex helper, but I haven’t used it.

OK so it’s how I thought – you have to run the test once for that. And then just point ExVCR to the place where you moved the file afterwards (the so-called custom cassettes path). Alright.

Haven’t looked up the IEx helper but you might be right that it could do explicit cassette recording. Hm, I might give it a try.