You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when VCR encounters a request it doesn't have a cassette for (and it's not recording), you get an UnhandledHTTPRequestError with details like this:
An HTTP request has been made that VCR does not know how to handle:
POST https://sandbox.some-api.com/soap
VCR is currently using the following cassette:
- /opt/app/spec/fixtures/vcr/some-api/some-action.yml
- :record => :once
- :match_requests_on => [:method, :uri, :soap_action]
This may already hint at my issue.
About SOAP
The API I'm testing uses SOAP. With SOAP APIs, the URL doesn't change based on the kind of request. The request itself include the action it wants to perform along with the data.
For example there could be two requests in a single test like:
# Request 1: Create a record
POST /soap
<Soap:Envelope>
<Soap:Body>
<CreateRecord> <field1>Value</field1> </CreateRecord>
</Soap:Body>
</SoapEnvelope>
# Request 2: Update the record
POST /soap
<Soap:Envelope>
<Soap:Body>
<UpdateRecord> <field1>New Value</field1> </UpdateRecord>
</Soap:Body>
</SoapEnvelope>
This means when recording and re-playing VCR cassettes, the content of the request itself has to be used to properly identify which request to use. I have a custom matcher soap_action to do this and it works great.
Problem
The issue is that when a request fails, I get an error like what I pasted above and it doesn't tell me which SOAP action caused the problem. Some of my tests perform 5 or 6 actions and it's hard to know which one went wrong.
Idea
It'd be great if matchers could define error messages or data to include in the final error message.
RSpec has a pretty nice strategy for this where you can define a matcher that includes custom messages.
matcher:include_valuedo |expected|
matchdo |actual|
actual.include?(expected)endfailure_message(actual)do"expected to find #{expected} in #{actual}, but didn't"endend
I've been trying to think of approaches that aren't too invasive to the codebase and of course are backwards compatible. One idea might be to make the Matcher class public and allow explicitly defining them with the normal matches? method but then aslo a new method like description?
Currently the message builder hardcodes looking for the body and headers matchers and manually includes details based on that. Perhaps this can all be made generic so each matcher includes its own description?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Background
Currently when VCR encounters a request it doesn't have a cassette for (and it's not recording), you get an
UnhandledHTTPRequestError
with details like this:This may already hint at my issue.
About SOAP
The API I'm testing uses SOAP. With SOAP APIs, the URL doesn't change based on the kind of request. The request itself include the action it wants to perform along with the data.
For example there could be two requests in a single test like:
This means when recording and re-playing VCR cassettes, the content of the request itself has to be used to properly identify which request to use. I have a custom matcher
soap_action
to do this and it works great.Problem
The issue is that when a request fails, I get an error like what I pasted above and it doesn't tell me which SOAP action caused the problem. Some of my tests perform 5 or 6 actions and it's hard to know which one went wrong.
Idea
It'd be great if matchers could define error messages or data to include in the final error message.
RSpec has a pretty nice strategy for this where you can define a matcher that includes custom messages.
I've been trying to think of approaches that aren't too invasive to the codebase and of course are backwards compatible. One idea might be to make the
Matcher
class public and allow explicitly defining them with the normalmatches?
method but then aslo a new method likedescription
?Currently the message builder hardcodes looking for the
body
andheaders
matchers and manually includes details based on that. Perhaps this can all be made generic so each matcher includes its own description?Beta Was this translation helpful? Give feedback.
All reactions