Rails: Prefer webmock over VCR

[stevepolitodesign]

Cassettes are tricky to maintain and are often fragile. Using webmock
allows for more fine-grained control.

Additionally, VCR risks leaking sensitive data.

[DoodlingDev]

friends don't let friends use VCR

[stevepolitodesign]

Note to self: I want to add my context to this decision, but I need to find the right words.

[brian-penguin]

I am against VCR (in the case of 90% of rails integration/unit style specs):

• When it requires at least one "real" request so someone somewhere needs to hit a production-ish service with real-ish data and if you don't have an accurate sandbox, you just hope that it doesn't matter
• When it's non-specific, what data are we stubbing exactly? Which peices do we care about testing for? Are we sure we are sending the right headers / tokens / full url path?
• When time matters. If the response came at 9pm on January 5th 2023 and that's the timestamps on the data in the VCR but I have a scope to look within the last month that I'm testing, does that mean I need to hand edit the yaml? Re-run the VCR generation every month?
• A well built mock for a single request is clear, it exists alongside the spec, and it lets you be specific for every bit of data that goes into it and what you expect out.
• Noisy! Re-running the VCR request likely rebuilds the entire file and it's hard to track what, if anything, actually changed
• Sensitive Data. If you're hitting a realish api, you've probably got real api keys/tokens/ids all of which should be filtered out

I am for VCR :

• when you are building a Mock for an external service you control. If I have the microservice to use sitting in the dir next to mine and I want it to respond to a consistent set of data consistently across multiple requests, perfect use case! When the api updates in the microservice, pull the change re-gen the cassette.
• In the past I've also seen a like "fake" server implementation where your tests all hit a real sinatra app that's faking a real api and I think I would prefer VCR over that unless the api is real simple
• When you're not using it in specs! Trying to build out an integration but don't trust the api which is down regularly, or inconsistent, or whatever but you just want like one good end to end smoke test you don't plan on committing? Go for it!

[JoelQ]

@purinkle I think this intersects with your talk proposal!

[nickcharlton]

This is my preference too.

I like to fine-tune my mock to only include what's relevant for a given request, and find it's very helpful when coming back later. When I've used VCR extensively, it's been hard to understand what's really important.

Once upon a time, I used to add VCR to record the requests and then replace them with Webmock, as I found this easier but these days I don't find it's necessary and wait for Webmock to tell me what's missing.