Closed GoogleCodeExporter closed 8 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
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
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
Here it is.
Original comment by alan.fra...@gmail.com
on 22 Dec 2009 at 11:10
Attachments:
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
I fixed the issue and submitted your patch. Thanks again!
Original comment by steve.mi...@gmail.com
on 8 Jan 2010 at 11:56
Original issue reported on code.google.com by
alan.fra...@gmail.com
on 11 Dec 2009 at 1:48Attachments: