[TIP] Changes to mock in subversion: please try

Michael Foord fuzzyman at voidspace.org.uk
Fri Oct 29 18:58:07 PDT 2010

On 26/10/2010 11:56, Michael Foord wrote:
> Hey Gregor,
> Thanks for replying. I've had some positive feedback on the feature in 
> "general", but I'm also convinced that it is too great a change to 
> just force on users (by default).
> What I will probably do is add new keyword arguments (yuck) to Mock 
> and patch to enable it ("spec_set" defaulting to False I think).

This change is now in the repository, which has changed to mercurial by 
the way. Patch and mock have new "spec_set" keyword arguments that 
enforce the stricter use of the object you pass in as a specification.


A 0.7.0 beta 4 release will follow soon, but first I need to update the 
docs to reflect the latest changes.

All the best,

Michael Foord

> All the best,
> Michael Foord
> On 23/10/2010 14:58, Gregor Müllegger wrote:
>> Hi Michael,
>> I kind of disagree that the new behaviour of the spec argument is a 
>> good thing.
>> At least that it's a good thing in every situation.
>> Take django's request object as an example. I often use a Mock() 
>> object as
>> request replacement to test views and middlewares. However 
>> middlewares often
>> attach new attributes to the request like the built-in 
>> SessionMiddleware that
>> makes the request.session attribute available.
>> Using the stricter meaning of `spec` here won't allow me to use this 
>> for my
>> request mocks to test middlewares.
>> This special case hit me this week. Testing a custom middleware like I
>> described above. I was using Mock(spec=HttpRequest) but this failed 
>> because
>> assigning a new attribute to the request was not allowed. But if I 
>> omitted the
>> spec argument, a test passed which should have failed because some code
>> accessed a request attribute that was not set yet.
>> Needless to say that you could work around this by "customizing" the 
>> mock with
>> `side_effect` etc.. But on the other hand its sometimes very 
>> "pythonic" to
>> assign new attributes to an existing object (and yep - sometimes its 
>> just
>> laziness and bad practice :-)).
>> So I think both interpretations of spec have their own use cases. 
>> What about a
>> new `weakspec` argument that implements the old behaviour?
>> I hope you understand what I want to express since my English isn't 
>> that good.
>> Keep up your great work on mock, it's really fun to use and made my 
>> life with
>> unittests in python much easier. Thank you!
>> Gregor
>> _______________________________________________
>> testing-in-python mailing list
>> testing-in-python at lists.idyll.org
>> http://lists.idyll.org/listinfo/testing-in-python


More information about the testing-in-python mailing list