[Python-Dev] Tweaking the stdlib test infrastructure
glyph at divmod.com
glyph at divmod.com
Tue Apr 24 18:45:04 CEST 2007
On 04:36 pm, collinw at gmail.com wrote:
>On 4/24/07, glyph at divmod.com <glyph at divmod.com> wrote:
>>On 12:39 am, collinw at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070424/37971f35/attachment.html
More information about the Python-Dev
mailing list