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
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
