[Twisted-Python] Adding mock as a test suite dependency
kevin.horn at gmail.com
Mon Oct 22 14:09:39 EDT 2012
On Sun, Oct 21, 2012 at 9:45 PM, Julian Berman <julian at grayvines.com> wrote:
> 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
> 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
> 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
> that difficult anyhow, it *is* just a bit more clutter to do so without
> 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
> of code that clutter the test method.
> To give a specific example, as I write this I'm writing tests for #6143
> 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
> 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)
> 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
> it to, and that debug is being called. Another test will test that debug
> what it's supposed to, also in isolation.
> Of course none of the objects I used there were very interesting, but mock
> similarly terse syntax for creating mocks with attributes, return values,
> 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.
> 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
> and it'd only be a dep for running the tests (and presumably only a
> 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 :)
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Twisted-Python