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)
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.
If you want to put together the "attrs" version, I'd be happy to look it
over and accept it.
Here it is.
Attachments:
mox-attrs.patch 3.7 KB
Sorry for the huge delay on this. I just patched this, and
testCantMockPrivateAttributes is failing. I'm looking into it now.
Comment #6 on issue 15 by steve.middlekauff: CreateMock should support
arbitrary attribute setting
http://code.google.com/p/pymox/issues/detail?id=15
I fixed the issue and submitted your patch. Thanks again!