Issue 11 in pymox: Support for properties

[codesite...@google.com]

Comment #2 on issue 11 by alan.franzoni: Support for properties
http://code.google.com/p/pymox/issues/detail?id=11

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.

Attachments:
property_handling.patch 1.8 KB

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[codesite...@google.com]

Comment #3 on issue 11 by smiddlek: Support for properties
http://code.google.com/p/pymox/issues/detail?id=11

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?

[codesite...@google.com]

Comment #4 on issue 11 by smiddlek: Support for properties
http://code.google.com/p/pymox/issues/detail?id=11

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)

[codesite...@google.com]

Comment #5 on issue 11 by sean.snyders: Support for properties
http://code.google.com/p/pymox/issues/detail?id=11

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"

[codesite...@google.com]

Comment #6 on issue 11 by sean.snyders: Support for properties
http://code.google.com/p/pymox/issues/detail?id=11

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

[codesite...@google.com]

Comment #7 on issue 11 by alan.franzoni: Support for properties
http://code.google.com/p/pymox/issues/detail?id=11

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?

Attachments:
prop.py 427 bytes