[Twisted-Python] Adding mock as a test suite dependency

[Kevin Horn]

On Sun, Oct 21, 2012 at 9:45 PM, Julian Berman <julian at grayvines.com> wrote:

> Hi.
>
> I'd like to gauge any interest in (or resistance towards) adding mock
> (http://www.voidspace.org.uk/python/mock/mock.html) as a dependency for
> the
> test suite.
>
> In short, while I don't necessarily feel strongly about behavior vs. state
> based verification being preferred in a general sense, I think both have
> their
> place when used with sensibility. (Sorry, I know that's not saying too
> much of
> substance, but I'm trying to ward off a discussion on whether or not it
> has a
> place at all if possible).
>
> The *benefit* though for me in having mock present is that it decreases the
> lines of code necessary to write stubs and mocks. While doing so is not
> really
> that difficult anyhow, it *is* just a bit more clutter to do so without
> mock,
> and the extra 3 or 4 lines mean that in more than one instance I have found
> myself pick a different strategy than I would have because of the extra
> lines
> of code that clutter the test method.
>
> To give a specific example, as I write this I'm writing tests for #6143
> (which
> will hopefully let trial drop into a debugger on an error or failure rather
> than at the outset of a test run). To do so I want to write tests that look
> like:
>
>     def test_itDebugsOnError(self):
>         result = mock.Mock()
>         exc_type, exc_value, tb = mock.Mock(), mock.Mock(), mock.Mock()
>
>         decorated = DebugDecorator(result)
>
>         with mock.patch.object(decorated, "debug") as debug:
>             decorated.addError(exc_type, exc_value, tb)
>
>         debug.assert_called_once_with(tb)
>         result.addError.assert_called_once_with(exc_type, exc_value, tb)
>
> where I want to test that the decorated test result is being used as I
> expect
> it to, and that debug is being called. Another test will test that debug
> does
> what it's supposed to, also in isolation.
>
> Of course none of the objects I used there were very interesting, but mock
> has
> similarly terse syntax for creating mocks with attributes, return values,
> etc.
> amongst a bunch of other useful features which I'll be happy to elaborate
> on if
> anyone would like, I just had the above example at hand.
>
> To add a few more notes:
>
>  - mock is in the stdlib starting with 3.3 as unittest.mock, which as I
>    understand it is the first version of Py3 for which support is planned.
> So
>    really all that'd be needed would be to add mock as a dependency on 2.X.
>
>  - it's a single file with no external deps, so installation is not
> difficult,
>    and it'd only be a dep for running the tests (and presumably only a
> subset
>    thereof that chose to use it)
>
>  - there are other mocking libraries, but I don't like any of the others as
>    much personally for various reasons.
>
>  - I'd be willing to do the small amount of work to add it if there'd be
>    interest :)
>
>
> Cheers,
> Julian
>
>
I like mock, but for me, using mocks is a method of last resort.  I don't
see a lot of need for it in internal Twisted tests (except maybe in adbapi?
 I don't know what the tests for that currently look like, but it seems a
logical place).

Kevin Horn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://twistedmatrix.com/pipermail/twisted-python/attachments/20121022/cf26cb29/attachment.htm