Mocking is not completely undone when decorated tests are nested #481
Comments
|
there are multiple issues that I see
I think applying these two design patterns will eliminate the issue |
That's the plan, but replacing the mock definitions in over 700 tests takes time.
That has no effect, even if the two use cases occur in different modules. As far as I can tell, it affects all discovered
That is true, but I was lazy and just wanted to run an already existing test with some additional constraint. So, I just defined the new test case with decorator and called the existing one.
Yes, there are a few more workarounds I can think of, but I wanted to share my findings nevertheless. Because someone might also consider this unexpected behavior. For what it's worth, it just occurred to me, that this problem is not limited to the use of two mocking libraries. Even if one wants to perform real requests, those will fail. I have extended the gist and get this new exception: I do appreciate your lack of enthusiasm for "fixing" this. My primary goal was to document this. |
|
I do not understand why that fails, there is even no decorator on the method I think have you raised your concerns in |
No, because Please note what is happening in the gist: The alphabetical order of the test cases ensures that a real request is required in a test before and after applying the In the current state of the gist,
I have not checked the code, but I believe the problem lies in the method of how mocked objects are stored. From the gist we know, that the problem only occurs after the nesting of I'd like to point out, that this is pure speculation: It looks like mocked objects (i.e. the originals) get stored in a "global variable". By nesting the decorator a mock gets stored in this variable. And when the mocked objects get restored we end up with a mock in the following test case that we do not intend to mock. I hope I was able to sufficiently explain what I think is happening. If you are willing to fix this, I would be very grateful. If not, we now have a description including workarounds that should be considered as better practice anyway. 🙂 |
|
As someone who has experienced the painful (but ultimately gratifying) transition from I've managed this transiiton in the past by making a dedicated utility module which encapsulates all use of As another thought to toss out there, in case it helps: avoid nesting # caveat emptor: I haven't tested this
_responses_active = False
def reentrant_activate(func):
@functools.wraps(func)
def wrapped(*args, **kwargs):
global _responses_active
if _responses_active:
return func(*args, **kwargs)
try:
_responses_active = True
return responses.activate(func)(*args, **kwargs)
finally:
_responses_active = False
return wrapped |
|
copy gist here to track the history: import unittest
import requests
import responses
class TestRequest(unittest.TestCase):
def test_a(self):
self.assertEqual(200, requests.get("https://www.google.com").status_code)
@responses.activate
def test_b_response_1(self):
responses.add(responses.GET, "http://example.com/1", body="Hello 1")
self.assertEqual(b"Hello 1", requests.get("http://example.com/1").content)
@responses.activate
def test_b_response_2(self):
self.test_b_response_1()
def test_c(self):
response = requests.head("https://www.google.com")
self.assertEqual(response.status_code, 200) |
* clean patcher on exit * add tests and comments Closes #481
First of all, I'd like to point out that I only noticed this problem in a project where HTTP requests are mocked with multiple libraries (I know, bad style).
Environment
Steps to Reproduce
responsesandhttpretty.responses.activatewithin another test method, that is also decorated withresponses.activate.httpretty.activatewill fail, if it is executed after the test including the nesting is executed.To illustrate this, I have created a gist.
Expected Result
Mocks introduced my the
responsespackage are completely rolled back, even if there is a nesting of mocks.Actual Result
To illustrate this, I have created a gist:
responses.activate), all tests in the gist will pass.The text was updated successfully, but these errors were encountered: