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

exarkun at twistedmatrix.com exarkun at twistedmatrix.com
Mon Oct 22 12:46:08 EDT 2012

On 03:00 am, glyph at twistedmatrix.com wrote:
>On Oct 21, 2012, at 7:45 PM, Julian Berman <julian at grayvines.com> 
>>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 
>>myself pick a different strategy than I would have because of the 
>>extra lines
>>of code that clutter the test method.
>This seems like a pretty small benefit; adding a new dependency affects 
>lots of people and introduces a new point of failure in the 
>installation process, especially for Windows users who already have a 
>devil of a time getting Twisted installed.
>Also I don't particularly like the testing style associated with Mock. 
>I think it might discourage us yet further from writing verified fakes, 
>i.e. supported in-memory implementations of things like IReactorTCP, 
>that have somewhat intricate behavior that's tedious to emulate with 

I'm also not a huge fan of the *unverified* mock style of testing.  I 
don't think anything says that mocks *have* to be unverified, though it 
seems they're often used that way.

The mock library that got added to the stdlib has the notion of 
constructing a mock using another object as a template.  I haven't used 
this feature, but it seems like the intent is to at least take a step 
towards verification.  It'd be nice if someone who knows more about the 
features of this library could give some examples.

In case anyone isn't clear, the problem with unverified fakes is that 
they either start out incompatible with the objects they're fakes of, or 
else they become incompatible with them over time.  Once they're 
incompatible, the tests that use them become significantly less useful, 
since they demonstrate little or nothing about what will happen when you 
try to use the code for real.

Verified fakes solve this problem by adding assertions that objects and 
their fakes have the necessary overlap in either interface or 
functionality in order for the tests using them to be valid.

Beyond that, considering the particular example presented, I wouldn't 
actually use mocks to test this.  The real object, the debugger, should 
be perfectly usable in unit tests.  It doesn't allocate or depend on 
expensive resources, it doesn't do network I/O, etc.  Mocks are perhaps 
an attractive nuisance that distract from coming up with a better test.

>Personally I'm -0.  Don't let that stop you from cooking up a patch 
>that would include it though, I might be in the minority here.

More information about the Twisted-Python mailing list