This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Requesting Mock Object support for unittest.TestCase
Type: enhancement Stage:
Components: Library (Lib) Versions:
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: purcell Nosy List: mattruss, purcell, rhettinger
Priority: low Keywords:

Created on 2003-03-22 20:05 by mattruss, last changed 2022-04-10 16:07 by admin. This issue is now closed.

File name Uploaded Description Edit
unittest.diff mattruss, 2003-03-22 20:08 Modifications to support mocking objects
unittest.diff mattruss, 2003-04-09 22:53 Updated context diff mattruss, 2003-04-10 00:32 unittests for mockobject faciilties
Messages (6)
msg53817 - (view) Author: Matthew Russell (mattruss) Date: 2003-03-22 20:05
I previously submitted a patch (sf id 706590),
since I was following'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:

This patch adds one method - createMockInstance
(classDef, overrides, *initArgs, **initKwds)
to unittest.TestCase, and two classes MockFactory and 

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?)

msg53818 - (view) Author: Matthew Russell (mattruss) Date: 2003-04-09 22:53
Logged In: YES 

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 using this and not be thrown back 
out to the command line)
msg53819 - (view) Author: Matthew Russell (mattruss) Date: 2003-04-10 00:32
Logged In: YES 

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)
msg53820 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-07-20 00:16
Logged In: YES 

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.
msg53821 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-01-01 07:01
Logged In: YES 

Steve, do you can to pronounce on this one?
msg53822 - (view) Author: Steve Purcell (purcell) (Python triager) Date: 2004-01-22 15:37
Logged In: YES 

Hi Matthew and Raymond,

Even though I'm a regular mock user, I'm currently not keen
to add Mock classes to I much prefer that 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 there is a danger of freezing a moving target,
then being bound to support it and maintain backward


(Apologies for the delays in processing these SF issues.
They are due to extensive and ongoing work and personal
Date User Action Args
2022-04-10 16:07:51adminsetgithub: 38200
2003-03-22 20:05:42mattrusscreate