MarkBerlin78 / pymox

Automatically exported from code.google.com/p/pymox
Apache License 2.0
0 stars 0 forks source link

CreateMock should support arbitrary attribute setting #15

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
At the present time, Mox has one shortcoming: whenever you need to set
attributes on an instance, you need to create the mock object and then set
attributes on it.

This is often the case for attributes that are usually set in the object's
__init__ method and can't be easily inferred by CreateMock, e.g.

class MyClass(object):
  def __init__(self):
    self.a = 1

# you must mock it this way:

m = Mox()
mockobj = m.CreateMock(MyClass)
mockobj.a = 1

even though this is usually done in setUp(), it might get boring and make
unit tests less and less readable.

This patch lets arbitrary kw args to be supplied to createmock, e.g.

mockobj = m.CreateMock(MyClass, a=1)
self.assertEquals(1, mockobj.a)

This makes it easy to both add instance attributes and to change instance
attribute values from the default (class defined) value.

Original issue reported on code.google.com by alan.fra...@gmail.com on 11 Dec 2009 at 1:48

Attachments:

GoogleCodeExporter commented 9 years ago
I'm not a huge fan of this syntax, but the proposal does make sense.  I wonder 
if it 
might make more sense to provide a MockOptions object to the ctor, which could 
be 
setup with these params, and possibly other configuration? or maybe just a 
named 
argument that takes a dict?

I'm not sure, but I just don't want to paint us into a corner with an overly 
complicated 
ctor down the  line.

d = { 'a': 1}
m.CreateMock(MyClass, attrs=d)

Original comment by steve.mi...@gmail.com on 21 Dec 2009 at 5:00

GoogleCodeExporter commented 9 years ago
Well... I think it's a matter of test case design, I don't really know how this 
is used at your facilities.

I rarely create the same mock object multiple times while in a test - if I have 
the need to do so, I'll probably set 
it up in setUp() . Of course you fear that this change might prevent any other 
possibile argument to be passed to 
CreateMock in the future, because the kwargs behaviour could break existing 
unit tests.

Hence I think the "attrs" version makes perfect sense and it's all right, just 
say so if you prefer me to code the 
patch.

Original comment by alan.fra...@gmail.com on 22 Dec 2009 at 8:27

GoogleCodeExporter commented 9 years ago
If you want to put together the "attrs" version, I'd be happy to look it over 
and accept it.

Original comment by steve.mi...@gmail.com on 22 Dec 2009 at 8:42

GoogleCodeExporter commented 9 years ago
Here it is.

Original comment by alan.fra...@gmail.com on 22 Dec 2009 at 11:10

Attachments:

GoogleCodeExporter commented 9 years ago
Sorry for the huge delay on this.  I just patched this, and
testCantMockPrivateAttributes is failing.  I'm looking into it now.

Original comment by steve.mi...@gmail.com on 8 Jan 2010 at 11:30

GoogleCodeExporter commented 9 years ago
I fixed the issue and submitted your patch.  Thanks again!

Original comment by steve.mi...@gmail.com on 8 Jan 2010 at 11:56