PreparedRequest instances are modified by responses
Describe the bug
As you can see in https://github.com/getsentry/responses/blob/b68e51388e08399a8828633910eac49d6fd35e2b/responses/init.py#L1067 responses, is modifying PreparedRequest instances to incorporate additional attributes. This is fine in the context of responses, this is not however when this data is returned to the clients.
Could you modify responses so that the behavior from a client perspective is the one of requests (ie: no additional attributes in objects) ?
Thanks again
Additional context
In the context of writing tests against HTTP behavior that cannot be reproduced with a real live scenario (such as an HTTP failure response from the server), I am trusting my test suite to be able to handle those scenarios and if I see that a PreparedRequest contains an attribute, I assume it will exists in production code as well the day such issue will occur (could be years after deployment time in such scenarios).
Version of responses
0.25.3
Steps to Reproduce
import requests
import responses
def test_params_in_prepared_request():
responses.get("https://the_test.url", status=403)
response = requests.get("https://the_test.url?param=value")
try:
response.raise_for_status()
except requests.RequestException as e:
print(e.request.params) # Without responses, an AttributeError will be raise ('PreparedRequest' object has no attribute 'params')
Expected Result
I expect the same failure as in production in my test run
Actual Result
The AttributeError is not raised when accessing params on a PreparedRequest
Could you modify responses so that the behavior from a client perspective is the one of requests (ie: no additional attributes in objects) ?
So where would you put the additional state that responses needs and do it in a backwards compatible way?
The way these params are modified should be considered a bug:
https://github.com/getsentry/responses/blob/93d321222c79b9b931d770fbd94020bad0294297/responses/init.py#L1057-L1058
This means it is not possible to mock an api that returns a JSON list with one item.
@patrickhodel you started with an issue that you access an attribute that does not exist. In general, any linting tool should have caught it on your side, since requests do not have this attribute
your second comment describes something else, completely unrelated.
Please provide minimal viable example that shows that responses modifies some parameters in the incompatible way.
This particular piece of code exists for more than 4 years and never caused any issue
@beliaev-maksim Thanks for your quick feedback. Upon further debugging and trying to create a minimal viable example I discovered that some other code in our environment does the same kind of conversion to the response as in the snippet I posted. Sorry for the noise.