Open GoogleCodeExporter opened 9 years ago
Also then I would get enough willing to end up with implementation of my
.assert_filtered_by thing, because right now it is ugly, I would like to see it
as mock property, not a function (you can see example here
http://www.redhotchilipython.com/en_posts/testing_python/09-django-specific-test
ing.html ).
Thanks!
Original comment by k...@k-bx.com
on 22 Mar 2012 at 5:35
By the way, you shouldn't need either your __init__ or your _child_mock. Your
__init__ is empty (so the default would be identical), and _get_child_mock will
use the class of the parent mock by default as well.
Original comment by fuzzyman
on 23 Mar 2012 at 12:16
Oh, nice to know that, thanks! I'll just throw away them, then.
Original comment by k...@k-bx.com
on 23 Mar 2012 at 3:05
Oh, yeah, I don't even remember why did I wrote the __init__ in a first place
:) it doesn't actually do anything.
Original comment by k...@k-bx.com
on 23 Mar 2012 at 3:06
I don't think a change is needed to mock to support this, writing your own
wrapper round patch to do this is trivial:
>>> from mock import patch, DEFAULT, MagicMock
>>> class MyMock(MagicMock): pass
...
>>> def my_patch(target, new=DEFAULT, spec=None, create=False, spec_set=None,
autospec=None, new_callable=None, **kwargs):
... if new is DEFAULT and new_callable is None:
... new_callable = MyMock
... return patch(target, new, spec, create, spec_set, autospec, new_callable,
**kwargs)
...
>>> foo = object()
>>> with my_patch('__main__.foo') as m:
... pass
...
>>> m
<MyMock name='foo' id='4299881744'>
Original comment by fuzzyman
on 25 Mar 2012 at 3:38
I'm re-opening this issue. I've come round to thinking that patch.DEFAULT_MOCK
(or similar) isn't an unreasonable feature request. I'm not certain it will get
into 1.0, but I'm considering it. A patch (no pun intended) with tests and
documentation would improve its chances. ;-)
Original comment by fuzzyman
on 14 Apr 2012 at 10:01
There's a problem here. I tried something similar to this, but got
ValueError: Cannot use 'autospec' and 'new_callable' together
Why is that? I mean, my new_callable is a subclass of MagicMock, it would be
natural to let it autospec.
Original comment by k...@k-bx.com
on 9 May 2012 at 12:08
The issue is that create_autospec creates the mocks for you, so it would need
modifying to be able to take a _mock_class argument (or similar) to use
something other than the standard MagicMock.
Original comment by fuzzyman
on 9 May 2012 at 12:29
Yeah, I think that's that would be the best way (I think it could be
implemented in terms of DEFAULT_MOCK feature also).
Original comment by k...@k-bx.com
on 9 May 2012 at 12:53
Original issue reported on code.google.com by
k...@k-bx.com
on 22 Mar 2012 at 5:33