WebMock VS vcr

If you want to check out an alternative to VCR, have a look at webmock.

Well, that's why your test says: "When the API responds like this I do that". People hate on ruby but webmock makes it very nice to mock/stub that, or for python there's responses. For the database you can use a local database with factories to easily create the data you need for each test and clear it between tests.

Man if you think python has great mocking/testing support, you check out some ruby tests! Honestly some of the best testing libraries that pioneered approaches that are becoming more common elsewhere, such as the expectations syntax. And now that I'm coding more in python I find myself missing libaries like webmock, letting you stub web reqests in a way that's agnostic of the HTTP/web libary, chef's kiss.

In order to keep our test suite faster and consistent, we need to mock our http requests. A simple and good way to achieve this is using the Webmock gem which allow easily mock the http responses for your requests.

We can avoid managing HTTP communication with our dependency. Instead, we'll stub out how we expect it to respond. In this case, we'll use webmock to stub out a response at the HTTP layer.

The other option is to mock the web requests to Hetzner - this: https://github.com/bblimke/webmock or similar may help.

There are fine istructions in WebMock README. I want to share it here for reference:

You can find the setup instructions and examples on how to use WebMock, in their github documentation. WebMock will prevent any external HTTP requests from your application so make sure you add this gem under the test group of your Gemfile.

Basically, it's a record/replay tool, similar to VCR for Ruby, but on steroids and powered by AI (khm GPT khm).

I don't think it's right to say "pythagora generates integration tests". It's more of a "replay manual tests as fixtured unit tests," which makes it similar to (but more powerful than) VCR for Ruby HTTP. What I've always wanted for these kinds of "request recorders" is a way to re-validate the test fixtures over time.

For example, they might expect to be able to mock calls to your API with something like VCR or Responses.

I also started from the same starting point but then discovered and started using VCR for creating http stubs - https://github.com/vcr/vcr. It allowed me to write against more realistic and complex test scenarios but didn't support databases.

If you had bit more complex workflows or less time - you could start using a VCR library to mock out API interactions and then continue with your dockerised DBs.

I generally will use vcr[0] or something similar to record requests and then I write tests and code against that.

3rd parties go down, it happens. In general a system that is dependent on a third party should have some non exceptional behavior when that happens.

So if I’m not setup with vcr, and 3rd party is down- I would on the behavior for what happens when it’s down.

[0] https://github.com/vcr/vcr

With external APIs, you can also make use of a gem like VCR. I prefer mocks (plus unit tests around the actual deserialization of the response) to VCR in most cases, but the end result is about the same.

A way to avoid this is using the VCR gem.

We'll use a tool called vcr to capture real HTTP requests and responses, storing and using them from then on. VCR's language and terminology leans heavily into its real-world analogue. If you don't know what a VCR is, it's a box we used to hook up to TVs to watch movies before DVD players. If you don't know what a DVD player is, it's a box we used to hook up to TVs to watch movies before streaming.

[1] https://github.com/vcr/vcr