On Tue, Sep 17, 2013 at 10:32 +0200, Antonio Cuni wrote:
> On 13/09/13 12:33, holger krekel wrote:
> > monkeypatch.setattr("os.path.abspath", lambda x: "/abc")
>
> speaking about possible APIs, what about the following?
>
> monkeypatch("os.path.abspath = foo")
>
> I find it much more readable than the two or three argument
> versions, and it's in a way similar to what we have for
> py.test.raises("...").
> The drawback is that the implementation is probably a bit trickier
> than what it is now.
Not sure it would even be that useful TBH and would indeed be trickier
to implement, i guess. Maybe it's better to rather think about
higher level helpers than argue much about the setattr() convenience.
Apart from the proposed setattr shortcut, i am also thinking of
direct mock (the lib from Michael Foord) support:
mock = monkeypatch.setmock("os.path.abspath")
call_something_with_triggers_the_mock()
assert mock.called_once_with(...)
With >=py3.3 this could just work, on older Pythons ``setmock``
would skip the test if "mock" is not importable.
However, i dislike parts of the mock API design, in particular that
the "mock" object is send to applications but also provides assertions
and mock-specific data attributes. If your app has attributes or
methods like "method_calls", "called", "call_args" etc. then you can
not mock it. Instead mock's API should rather work like this:
m = mock.Mock()
... pass m somewhere ... (having virtually no special attributes)
assert mock.assert_once_called_with(m, ...)
This way "mock.*" and assertions would become a "meta" api, strictly
separated from the mock objects that are sent into an application,
avoid any conflicts. Practicality might beat purity, though. mock
is already widely used ...
cheers,
holger
_______________________________________________
Pytest-dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/pytest-dev
