On Sun, Oct 21, 2012 at 9:45 PM, Julian Berman <jul...@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
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
