On 03:00 am, gl...@twistedmatrix.com wrote: >On Oct 21, 2012, at 7:45 PM, Julian Berman <jul...@grayvines.com> >wrote: >>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. > >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 >Mock.
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. Jean-Paul >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. > >-glyph _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
