Comment 1 for bug 1687039

Hey David, Thanks for the report.

So i'm sorry to have flipped behaviour like that, interestingly the reason I did was because someone filed a bug report saying the old way was unintuitive. At the time I did consider chaining up from inner to outer mocks, but there are a few implementation details that make that difficult and that was the first time i'd even heard of somebody doing nested mocks.

So before i commit to anything i'd really like to understand the use case because I've never seen why people use requests-mock this way. You say "I was writing a test that needed a new mock", what's the rationale for using a new mock instead of adding a new route to the old mock?

The way i've always done my tests is (untested):

class TestStuff(testtools.TestCase):

    def setUp(self):
        super(TestStuff, self).setUp()
        self.requests_mock = self.useFixture(rm_fixture.Fixture())
        // some common routes, eg auth
        self.requests_mock.get('https://test.com/login', json={})

    def test_something(self):
        // test specific mocks
        self.requests_mock.get('https://test.com/path', json={})

        // do test

(I like the fixture because we use fixtures elsewhere, but all it does is creates a requests_mock.Mocker(), call rm.start() and addCleanup(rm.stop) so you don't need to use it)

This means that you have one mocker object per test and your test suite builds up relevant mocks in the setUp, and typically we have a test class inheritence that means you get all the common mocks based on what you are inheriting.

I'm not claiming my way is correct, but approaching tests that way I'm not sure why you're in a situation where you have a new mocker object for a test and that test also relies on a mocker that was set up earlier. Why not just reuse the first one?