VCR middleware #93
VCR middleware #93
Conversation
| configuration.logger | ||
| end | ||
|
|
||
| def cassette_name |
There was a problem hiding this comment.
At this point, the most tricky part is cassette_name.
It should define cassette name based on some data from the request. But to do this right we need to be careful.
I'm not sure we could pass this name from Cypress, b/c BE request could be sent from anywhere (ex. graphql mutation in form submit)
There was a problem hiding this comment.
For those projects using GraphQL it would be nice to detect it as well. Right now it considers /graphql as a path for endpoint, but it could be different.
Also, no guarantee, that the operation name will be a part of params
| end | ||
|
|
||
| def run_with_cassette | ||
| VCR.use_cassette(cassette_name, { :record => configuration.vcr_record_mode }) do |
There was a problem hiding this comment.
Not sure 🤔 if this will work as it only wraps one request.
I think we actually need two endpoints, one to inject a cassette and one to eject a cassette.
There was a problem hiding this comment.
@grantspeelman As the doc says https://www.rubydoc.info/gems/vcr/VCR:insert_cassette They recommend to use use_cassette instead of pair of insert-eject calls.
I guess use_cassette block should work the same way. The only change here is wrapping "normal" app flow.
Why do you think that insert/eject will perform differently?
I tested it on the real project under test env, and I've got a cassette written with 2 API calls inside.
There was a problem hiding this comment.
guess i just don't see how "use_cassette" approach will work, but maybe once you have a working example it will make sense 👍🏽
There was a problem hiding this comment.
I, it's making sense now.
Every single request it wrapped in it's own VCR cassette 👍🏽 and it's not really controlled from within Cypress.
This a is a good start and could help some teams around certain scenarios.
Maybe all that is still needed from Cypress is the ability to set a cassette prefix so that different scenarios can use different cassettes.
There was a problem hiding this comment.
@grantspeelman I was thinking about some sort of temporary key-value storage, that users can setup in the config and populate values using appCommand during the test. This storage could be reseted the same way as we do it for DB before/after each test. In that perspective, we could pass the whole name for cassette, not just a prefix.
But maybe it's too much.
There was a problem hiding this comment.
the whole name for cassette sounds like a good idea, also gets around the issue of having to try and generate a cassette name. Like that idea 👍🏽
|
I have tackled this differently in #103 |
|
@grantspeelman @MUTOgen closing, per #103. |
|
@justin808 #103 has to be used in a very specific way. |
|
@MUTOgen any new feedback on this one? |
|
@justin808 Nothing specific to mention. |
|
@MUTOgen should we close this one? |
|
Let's keep this branch until client migration |
TBD