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.

classification
Title: TestLoader.loadTestsFromName does not use suiteClass attribute to create TestSuite instances
Type: behavior Stage: patch review
Components: Library (Lib) Versions: Python 3.1, Python 3.2, Python 2.7, Python 2.6
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: michael.foord Nosy List: MarkRoddy, michael.foord, r.david.murray
Priority: normal Keywords: patch

Created on 2009-09-08 20:03 by MarkRoddy, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
unittest.patch MarkRoddy, 2009-09-08 20:03 patch for unittest.py to correct observed behavior and two tests fixtures that check for desired behavior
unittest.trunk.patch MarkRoddy, 2009-09-08 21:27
Messages (4)
msg92427 - (view) Author: Mark Roddy (MarkRoddy) * Date: 2009-09-08 20:03
The TestLoader class in unittest.py has an attribute 'suiteClass' that 
is used to create instances of TestSuite object(s) in the process of 
loading tests.  If it is desired to subclass the TestSuite class then 
consumers may set this attribute on a TestLoader object in order to 
override what TestSuite class gets instantiated (a pythonic version of 
the factory method pattern).  

However, the loadTestsFromName() on the TestLoader class does not use 
this attribute to create TestSuite instances, and instead has a hard 
coded reference to the unittest.TestSuite class.  This results in the 
base class being created instead of a possibly desired subclass that 
has been specified via this attribute.  

Solution for this issue is to change the loadTestsFromName() method to 
use the suiteClass attribute when creating TestSuite objects instead 
using a reference to the TestSuite class.  Included is a patch that 
implements this behavior as well as two additional test for the 
test_unittest.py file which expose this issue if run against an 
unpatched version of unittest.
msg92430 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2009-09-08 20:24
I haven't run the tests, but a quick glance at the code makes me think
this is still probably an issue in 2.7/3.1.
msg92433 - (view) Author: Mark Roddy (MarkRoddy) * Date: 2009-09-08 21:27
The issue appears to be in the other versions mentioned from manual 
inspection.

Also adding another patch as unittest in the trunk has been broken 
apart into a package with several modules so the original patch will 
not work there.
msg92575 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2009-09-13 17:28
Committed revision 74783.
History
Date User Action Args
2022-04-11 14:56:52adminsetgithub: 51115
2009-09-13 17:28:51michael.foordsetstatus: open -> closed
resolution: accepted
messages: + msg92575
2009-09-08 21:27:49MarkRoddysetfiles: + unittest.trunk.patch

messages: + msg92433
2009-09-08 20:25:00r.david.murraysetpriority: normal

assignee: michael.foord
versions: + Python 3.1, Python 2.7, Python 3.2, - Python 3.0
nosy: + r.david.murray, michael.foord

messages: + msg92430
stage: patch review
2009-09-08 20:03:48MarkRoddycreate