[TIP] Some proposed additions to unittest.mock

[Chris Conway]

Hi, Julian,

Thanks for your comments...

On Mon, Apr 15, 2013 at 10:35 AM, Julian Berman <julian at grayvines.com>wrote:

> On Apr 15, 2013 1:11 PM, "Chris Conway" <clconway at google.com> wrote:
> >
> > I've recently started using the mock library in my code (transitioning
> from Mox) and I really like it a lot. There's a few little utilities I've
> written for myself and I wonder if you'd accept them as patches.
> >
> > First, I find that I strongly prefer to use autospecced instances for
> most of my mocks. To make that simpler, I wrote a create_strictspec()
> function as a wrapper around create_autospec() with instance=True.
> >
> > I also find that I frequently want a mock function that should never be
> called (e.g., in a test where I'm patching open() and testing a code path
> where no file is opened). This can be asserted ex post by checking
> call_count, but then you don't get any information about where the call
> occurred. Alternatively, you can use a NoncallableMock, but then you get a
> fairly opaque error: "TypeError: 'NonCallableMock' object is not callable".
> I find it preferable to use a utility method expect_never_called() to set
> an AssertionError side effect on the mock.
>
> I find this error message to be pretty transparent honestly.
>
I'd prefer something like: "AssertionError: Unexpected call:
mock_fn(actual_arg)". I guess it would be pretty easy to get something like
this without adding a new method by just implementing __call__ on
NonCallableMock to raise an exception.

> Hypothetically though, Mock's assertions are all state based and done
> after exercising, so starting to add preconfigured expectations would seem
> out of place to me. I personally wouldn't mind terribly much if you wanted
> to change the error message to say something more mock-specific, but
> nothing comes to me at the moment that would beat the current message.
>
I'm very glad to be freed of the tyranny of setting required expectations
in Mox. :-) But I think in cases like this an ex ante expectation is more
natural than an ex post assertion.

> I don't have a meaningful opinion on the first thing since unfortunately I
> don't use tightly spec'ed mocks as much as I should, mostly out of laziness
> :/. But it'd have to be fairly common to deserve a separate function for a
> single parameter.
>
I agree it seems a bit much to have a wrapper just for one parameter.
But... it's an optional parameter, which makes it easy to forget and I like
the protection of having a simple alias for the call.

> (Would love to hear more things you come up with coming from Mox
> certainly, there was someone else in the IRC channel who was discussing it
> [maybe that was you?])
>
Nope, wasn't me.

 > Do you think these would be helpful additions to the library?

> >
> > Best regards,
> > Chris
> >
> > _______________________________________________
> > testing-in-python mailing list
> > testing-in-python at lists.idyll.org
> > http://lists.idyll.org/listinfo/testing-in-python
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20130415/2a12f523/attachment.htm>