Tweaking the stdlib test infrastructure
Fast and simple: I want all stdlib test cases to stop subclassing unittest.TestCase and start subclassing test_support.TestCase. Why: With a single parent class common to the entire stdlib, adding new functionality/testing instruments to *every single test at once* becomes trivial. One example would be to move "regrtest -R"'s focus from module-level refleaks to test case-level refleaks (that is, looped execution of individual test cases, rather than test modules). I intend to implement this new refleak checking soon, if this base change goes ahead. How: At first, test_support.TestCase could be as simple as "TestCase = unittest.TestCase". Once we want to extend the test harness's capabilities, we change it to "class TestCase(unittest.TestCase): blah blah blah". All code under Lib/test/ is changed to subclass the proper class. test_support.run_unittest() can be modified to make sure that incoming classes inherit as they're supposed to. But that sounds like a lot of work: yes, but that's what we have regexes for. Most of this work can be done with a few global search-and-replace operations. So: any objections to making this change? Collin Winter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 23, 2007, at 8:39 PM, Collin Winter wrote:
Fast and simple: I want all stdlib test cases to stop subclassing unittest.TestCase and start subclassing test_support.TestCase.
So: any objections to making this change?
Please use the absolute package name test.test_support.TestCase. Remember that some of the code in the stdlib is released externally to Python (e.g. the email package), so their test suites have to be runnable in that deployment mode. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRi16v3EjvBPtnXfVAQKS4wQAiAaoIrhLhnnKxsrJL8RHZzPB9J3u98LJ EWZD7h9z0rXBEElOSDCQqZ3zlSVJNO5PGcogXPivrKE3Hg5t/pK88FCAMFNjv8iY sLK2fwpMlsGLLnIfGRbSOTxVvyEmuUEPQ5CuLUniPEMocE42bUi+7hpp5pLc2PDA U7dzYzGwBxA= =g+lH -----END PGP SIGNATURE-----
Collin Winter wrote:
Fast and simple: I want all stdlib test cases to stop subclassing unittest.TestCase and start subclassing test_support.TestCase.
Why: With a single parent class common to the entire stdlib, adding new functionality/testing instruments to *every single test at once* becomes trivial. One example would be to move "regrtest -R"'s focus from module-level refleaks to test case-level refleaks (that is, looped execution of individual test cases, rather than test modules). I intend to implement this new refleak checking soon, if this base change goes ahead.
How: At first, test_support.TestCase could be as simple as "TestCase = unittest.TestCase". Once we want to extend the test harness's capabilities, we change it to "class TestCase(unittest.TestCase): blah blah blah". All code under Lib/test/ is changed to subclass the proper class. test_support.run_unittest() can be modified to make sure that incoming classes inherit as they're supposed to.
+1
[...]
Servus, Walter
On 12:39 am, collinw@gmail.com wrote:
Fast and simple: I want all stdlib test cases to stop subclassing unittest.TestCase and start subclassing test_support.TestCase.
So: any objections to making this change?
Not an objection so much as a question - if these feature additions are generally interesting (and the ones you mentioned sounded like they are) why not simply add them to unittest.TestCase itself? After all, that is in the stdlib itself already.
On 4/24/07, glyph@divmod.com
On 12:39 am, collinw@gmail.com wrote:
Fast and simple: I want all stdlib test cases to stop subclassing unittest.TestCase and start subclassing test_support.TestCase.
So: any objections to making this change?
Not an objection so much as a question - if these feature additions are generally interesting (and the ones you mentioned sounded like they are) why not simply add them to unittest.TestCase itself? After all, that is in the stdlib itself already.
Because something like per-test refleak checking is completely useless when testing pure-python code. More generally, because not everything that will be useful for the stdlib's test suite will be useful to every single third-party test suite. It's also an issue of support: I want the freedom to add functionality to the stdlib's test suite without worrying about the impact on third-party unittest code. Collin Winter
On 04:36 pm, collinw@gmail.com wrote:
On 4/24/07, glyph@divmod.com
wrote: On 12:39 am, collinw@gmail.com wrote:
Fast and simple: I want all stdlib test cases to stop subclassing unittest.TestCase and start subclassing test_support.TestCase.
So: any objections to making this change?
Not an objection so much as a question - if these feature additions are generally interesting (and the ones you mentioned sounded like they are) why not simply add them to unittest.TestCase itself? After all, that is in the stdlib itself already.
Because something like per-test refleak checking is completely useless when testing pure-python code.
Not everybody outside the stdlib is using the python unittest module to test pure-python code.
More generally, because not everything that will be useful for the stdlib's test suite will be useful to every single third-party test suite.
I don't think that every single third-party test suite is using every single feature of the existing unittest module either, though.
It's also an issue of support: I want the freedom to add functionality to the stdlib's test suite without worrying about the impact on third-party unittest code.
This makes sense to me, and I won't belabor the point. I just wanted to give a gentle reminder that if this functionality is useful to the standard library, it's likely that there are other libraries it would be useful to. Not putting it into the supported library right away makes sense, but if this functionality does prove useful, please consider making it standard.
participants (6)
-
Barry Warsaw
-
Brett Cannon
-
Collin Winter
-
glyph@divmod.com
-
Neal Norwitz
-
Walter Dörwald