Support for properties

[GoogleCodeExporter]

I would like to mock classes with properties, but cannot find any example
for this.

When I try set expectations for a property the framework does not
understand the propery attribute. I then tried to set expectations for the
__get* and __set* method for that property, but still when using the
property from the mock-ed class in another class (the class to be tested)
the type of that property is a 'property' and the getter is never executed.

Do I have to manually bind the ID property of the mock class to the getter
and setter? What is the suggested best practice here?

Thanks!

Original issue reported on code.google.com by sean.sny...@gmail.com on 3 Aug 2009 at 8:25

[GoogleCodeExporter]

I thought this would be the right way:

mockedObject.property.AndReturn(value)

as this describes the intent well, and one can then test wether the getter and 
setter
for a mock object will be called or not.
But it turns out not to be possible, and this seemed to work (although I don't 
know
if the support for verifying getter/setter execution is possible):

mockedObject.property = value

Original comment by sean.sny...@gmail.com on 3 Aug 2009 at 8:31

[GoogleCodeExporter]

Hello, in my opinion properties should just be handled like instance 
attributes: they
should be completely ignored, so that they can just be manually set and read 
during
the tests - there should be no difference from an interface point of view from 
an
instance attribute and a property.

Patch attached, with tests.

Original comment by alan.fra...@gmail.com on 9 Oct 2009 at 9:45

[GoogleCodeExporter]

Thanks for the patch Alan.  I need to think a bit more about how properties, and
especially the backing functions should be handled.  In your patch, an
UnknownMethodException is raised, which doesn't seem quite right to me.  That
function is part of the public interface, so it should be callable.  

I'm not sure whether such functions should be included in the record / replay 
call
queue, or they should be given some kind of special status.  

I could imagine a property named "fullname", that would parse a single input 
string
and set self._sur_name and self._given_name, and I'm not sure how that should be
handled, since there are non-obvious side effects (not a direct 1:1 property 
access).
 For this, maybe a direct pass through (calling the real function) would work.

But now imagine the case where the function that handles the parsing calls to 
some
external service for parsing names based on locality (Chinese names, etc).  We 
don't
want that call in our tests... so it seems like the pass through isn't ideal.  

More and more, this looks like regular, mockable functions, with side effects 
that
may mutate instance state.  Does anyone else have any thoughts on this?

Original comment by smidd...@gmail.com on 14 Oct 2009 at 6:58

[GoogleCodeExporter]

Wait, the backing property functions are not actually callable, so your patch is
closer to okay.  Now we just need to figure out how to handle the possible side
effects, or state aggregation (globbing together sur and given name)

Original comment by smidd...@gmail.com on 14 Oct 2009 at 7:13

[GoogleCodeExporter]

My suggestion might have been misunderstood:
I want to be able to set expectations on the property during the recording 
stage of 
my test. This would be similar to setting expectations on any function call. I 
do 
not need special syntax. In the case of the fullname example:

mockedObject.fullname.AndReturn("JoeSmith")

As then I can mock my properties the way I like to and it is more consistent 
with 
the expectations setup as well as making the intent clearer than just 
'manually' 
assigning:

mockedObject.fullname = "JoeSmith"

Original comment by sean.sny...@gmail.com on 14 Oct 2009 at 7:20

[GoogleCodeExporter]

Also verifying whether the property setting was called or not during the replay 
stage also needs to be included.

Original comment by sean.sny...@gmail.com on 14 Oct 2009 at 7:23

[GoogleCodeExporter]

The fact that an attribute is a property should be *transparent* - that's what 
properties are for. It's an 
implementation detail that should not be exposed in a mock object's behaviour. 
The fact that a mocked 
object has a property should be treated just as if it had an instance attribute 
- and mock simply ignores those 
and lets the user to set and check them.

If i want to see if the tested object has read my mock object's attribute 
properly, I'll check whether a certain 
method returns the value I want. If I want to see that a mock object attribute 
has been correctly set by the 
object under test, i'll do an assertEquals() after the proper method.

Check the attached file, look at A and B classes: why should object of such 
classes be mocked differently?

Original comment by alan.fra...@gmail.com on 14 Oct 2009 at 7:46

Attachments:

• prop.py

[GoogleCodeExporter]

There seems to be the need to update the patch in order to be applied to current
trunk (r38); here it is.

Original comment by alan.fra...@gmail.com on 14 Dec 2009 at 3:33

Attachments:

• mox-updated-attribute.patch

[GoogleCodeExporter]

Hello, I don't like pinging, but is there any chance this (or any other 
solution) 
could be applied to the trunk?

Original comment by alan.fra...@gmail.com on 8 Apr 2010 at 1:23

[GoogleCodeExporter]

Sorry, this fell off my radar.  I'll patch it today.

Original comment by stev...@google.com on 8 Apr 2010 at 4:12

[GoogleCodeExporter]

Argh, sorry for the delay on this patch. D:

Original comment by steve.mi...@gmail.com on 20 Apr 2010 at 11:47

• Changed state: Fixed