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
classSomeClass:
defmethod(self, a):
returna*2deffacade(self):
self.method(4)
return'Done'deftest_some_class(mocker):
spy=mocker.spy(SomeClass, 'method')
o=SomeClass()
o.facade()
assertspy.calledassertspy.call_count==1print(spy.mock_calls[0])
# nicely outputs method arguments# call(<m.SomeClass object at 0x7febfed74518>, 4)print(spy.return_value)
# just tells us we have mock object here# <MagicMock name='method()' id='140651569552856'># it would be much better to have there# assert spy.return_value == 8# or, rather# assert spy.mock_calls[0].return_value == 8
Spy as context manager
That's probably kind of misusing mocker object, but in my case there's a quite long test and I want to restrict fragment of code where particular spy object is applied.
Thanks for taking the time to write your suggestions! Also appreciate the easy to follow examples.
Unfortunately none of the suggestions can be implemented without breaking the current interface, so we might need a new method name that returns an object that:
I run into a similar need of capturing return values from the object spied upon. My solution was a wrapper around unittest.mock.patch.object which adds a side-effect to stores both function call args as well as function result (return value or exception raised). But then I also recreated the same yield_fixture to guarantee the patched object would be restored, so basically I've duplicated quite a bit of pytest-mock. And I hate duplication. :)
If we can agree on what the solution should roughly look like,I can try writing up a PR.
What about mocker.watch() with same signature as spy()? It would basically work like patch.object, then after starting the patch apply a side_effect wrapper that registers call args/returnvalue/exceptions (I'm storing them as namedtuples, but can change that).
Activity
nicoddemus commentedon Jun 14, 2018
Hi @neumond,
Thanks for taking the time to write your suggestions! Also appreciate the easy to follow examples.
Unfortunately none of the suggestions can be implemented without breaking the current interface, so we might need a new method name that returns an object that:
Do you have any suggestions?
cc @fogo, which contributed
mocker.spyinitially.alexAubin commentedon Sep 23, 2019
Hello there,
just found this randomly while looking for some sort of "spy as context manager" feature. Though what naively imagined would be more like :
(not necessarily using
spy()as name if it's troublesome)The motivation would be to have something similar to
pytest.raiseswhich only works for exceptions as far as I understand.mocker.spy now also tracks return value
mocker.spy now also tracks return value
mocker.spy now also tracks return value
mocker.spy now also tracks return value
Track return value of spied functions (#155)
Mark90 commentedon Nov 13, 2019
I run into a similar need of capturing return values from the object spied upon. My solution was a wrapper around
unittest.mock.patch.objectwhich adds a side-effect to stores both function call args as well as function result (return value or exception raised). But then I also recreated the same yield_fixture to guarantee the patched object would be restored, so basically I've duplicated quite a bit of pytest-mock. And I hate duplication. :)If we can agree on what the solution should roughly look like,I can try writing up a PR.
What about
mocker.watch()with same signature asspy()? It would basically work like patch.object, then after starting the patch apply a side_effect wrapper that registers call args/returnvalue/exceptions (I'm storing them as namedtuples, but can change that).Mark90 commentedon Nov 13, 2019
Didn't notice that you already implemented this with 1.11. Please disregard my comment.
Awesome work by the way :)
[-]Spy improvements: capture return value, make spy a context manager[/-][+]Make spy a context manager[/+]nicoddemus commentedon Nov 18, 2019
@Mark90 indeed the issue was a bit confusing, thanks for bringing this to attention.
I've updated the title and mentioned that the return value has been implemented in 1.11. 👍