Closed GoogleCodeExporter closed 9 years ago
This is a known issue of using mock objects with mutable arguments. Copying
arguments by default would break "equality by identity" asserts.
See this discussion, including two solutions, in the documentation:
http://www.voidspace.org.uk/python/mock/examples.html#coping-with-mutable-arguments
Original comment by fuzzyman
on 15 Oct 2012 at 11:23
I understand you don't want to break equality by identity.
Having mulled this over a little more and compared mock's approach with other
mocking frameworks I've used in the past, I think the essential root problem
here is that method call expectations are expressed *after* the method under
test is called.
e.g. in RSpec-mock in Ruby you would do something like:
double.should_receive(:do_something).with({:key => 'value'})
double.do_something({:key => 'value'}) # passes
The advantage with this approach is that the expectation is evaluated at the
point of the method call and not some time later, eliminating the possibility
that the arguments being matched can be mutated in the interim.
To be clear, I'm not suggesting you implement this pattern in mock :-) just
wanted to brain dump my thoughts.
Original comment by t...@leach.it
on 15 Oct 2012 at 1:48
Sure, that's the record->replay pattern. mock is instead based on AAA
(Arrange->Act->Assert).
Original comment by fuzzyman
on 15 Oct 2012 at 1:50
Original issue reported on code.google.com by
t...@leach.it
on 12 Oct 2012 at 11:03