mirror of
https://github.com/jnunemaker/httparty
synced 2023-03-27 23:23:07 -04:00
77d11c6ca3
This PR fixes the issue(s) described in #713. To fix the logger option issue, I simply delete `Request.options[:logger]` when dumping. To fix the proc parser issue, I delete `Request.options[:parser]` if and only if `Request.options[:logger]` is a proc. If `Request.options[:logger]` is a regular class, `Marshal.dump` should proceed as normal. This should not affect the `Marshal.dump` behavior described in issue #143 and fixed by PR #618. I have added a feature spec to make sure marshalling the request works as intended, as well as a unit test to ensure `Marshal.load(Marshal.dump(req))` works as it should.
21 lines
974 B
Gherkin
21 lines
974 B
Gherkin
Feature: Supports marshalling with request logger and/or proc parser
|
|
In order to support caching responses
|
|
As a developer
|
|
I want the request to be able to be marshalled if I have set up a custom
|
|
logger or have a proc as the response parser.
|
|
|
|
Scenario: Marshal response with request logger
|
|
Given a remote service that returns '{ "some": "data" }'
|
|
And that service is accessed at the path '/somedata.json'
|
|
When I set my HTTParty logger option
|
|
And I call HTTParty#get with '/somedata.json'
|
|
And I call Marshal.dump on the response
|
|
Then it should not raise a TypeError exception
|
|
|
|
Scenario: Marshal response with proc parser
|
|
Given a remote service that returns '{ "some": "data" }'
|
|
And that service is accessed at the path '/somedata.json'
|
|
When I set my HTTParty parser option to a proc
|
|
And I call HTTParty#get with '/somedata.json'
|
|
And I call Marshal.dump on the response
|
|
Then it should not raise a TypeError exception
|