Issue 708125: Requesting Mock Object support for unittest.TestCase (original) (raw)
Created on 2003-03-22 20:05 by mattruss, last changed 2022-04-10 16:07 by admin. This issue is now closed.
Messages (6)
Author: Matthew Russell (mattruss)
Date: 2003-03-22 20:05
I previously submitted a patch (sf id 706590), since I was following www.python.com's notes on how to contribute - since using sf more i think i should of added it to this RFE. Since posting the orignal patch I have updated the code based upon sugestions from python-dev and others.
please view my origanal patch here: https://sourceforge.net/tracker/index.php? func=detail&aid=706590&group_id=5470&atid=305470
This patch adds one method - createMockInstance (classDef, overrides, *initArgs, **initKwds) to unittest.TestCase, and two classes MockFactory and MockMethod.
Since both these classes should never really be used outside the scope of a unittest, I thought it best to add them to the unittest module (allthough it is getting rather big - should be split into a package?)
Author: Matthew Russell (mattruss)
Date: 2003-04-09 22:53
Logged In: YES user_id=737261
I have made some changes to my patch - i hope it's made things clearer (?)
have also replaced 0/1's with False/True where appropriate added boolean kwd arg to main - exitsOnResult which if set to false will not do sys.exit (now you can run python -i test_mystuff.py using this and not be thrown back out to the command line)
Author: Matthew Russell (mattruss)
Date: 2003-04-10 00:32
Logged In: YES user_id=737261
I wrote these unittests first before i wrote the code. Hopefully proves that it works for new style classes and old (allthought tests are now a little out of date as the updated diff uses sets, therefore is 2.3 specific)
Author: Raymond Hettinger (rhettinger) * 
Date: 2003-07-20 00:16
Logged In: YES user_id=80475
Matthew, thanks for the patch. It gets a little better with each update (though it is still in dire need of a spell-check).
The cost/benefit of adding this to the unittest module is not clear. Perhaps, it would be worthwhile to present it on the newsgroup to tease out the idea, build a fan club for it, or come up with a simpler API.
My biggest issue with the unittest module is that it is already too extensive. One has to read a small book on the subject to get started. The number of doc pages, classes, and methods rank it as more complex than most of the net modules (with the notable exception of the email package). In Beck's TDD book (p. 119), he comments that some unittest packages are already too complicated for his tastes.
This patch would make the complexity issue worse. It takes longer to figure out how the use the patch that it does to create a small, easy-to-read, special purpose mock object.
Also, I'm concerned that MockObjects tend to create a false
sense of security in a situation where the actual object
behavior diverges from the simulated behavior. Also, to the
extent that a simulation is simple, it tends to discourage
adding tests that exercise all the nuances of a real object.
For example, a MockDatabase may simulate the expected
replies to some queries but doesn't behave enough like the
real thing to encourge tests on commits, rollbacks, cache
flushing, re-ordered tables, etc.
If this doesn't get added to the unittest module, it would certainly be worthwhile to post it to the Python Cookbook so that advanced users can get to it when they need it.
Author: Raymond Hettinger (rhettinger) *
Date: 2004-01-01 07:01
Logged In: YES user_id=80475
Steve, do you can to pronounce on this one?
Author: Steve Purcell (purcell) 
Date: 2004-01-22 15:37
Logged In: YES user_id=21477
Hi Matthew and Raymond,
Even though I'm a regular mock user, I'm currently not keen to add Mock classes to unittest.py. I much prefer that unittest.py should concentrate solely on providing test/test-runner infrastructure; there are a number of mock packages out there, and Python users can choose between them. Additionally, it is pretty straightforward to write code from scratch to mock out methods and instances.
Opinions in the XP community of mocking techniques and their merits are varied enough that even java folk are writing new mock frameworks, and by incorporating mock support into unittest.py there is a danger of freezing a moving target, then being bound to support it and maintain backward compatibility.
Regards, -Steve
(Apologies for the delays in processing these SF issues. They are due to extensive and ongoing work and personal commitments.)