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