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
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

On 4/23/07, Collin Winter <collinwgmail.com> wrote:
> Fast and simple: I want all stdlib test cases to stop
subclassing
> unittest.TestCase and start subclassing
test_support.TestCase.

Go for it!

n
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

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

iQCVAwUBRi16v3EjvBPtnXfVAQKS4wQAiAaoIrhLhnnKxsrJL8RHZzPB9J3u
98LJ
EWZD7h9z0rXBEElOSDCQqZ3zlSVJNO5PGcogXPivrKE3Hg5t/pK88FCAMFNj
v8iY
sLK2fwpMlsGLLnIfGRbSOTxVvyEmuUEPQ5CuLUniPEMocE42bUi+7hpp5pLc
2PDA
U7dzYzGwBxA=
=g+lH
-----END PGP SIGNATURE-----
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

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
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

On 4/24/07, glyphdivmod.com <glyphdivmod.com> wrote:
> On 12:39 am, collinwgmail.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
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

On 4/23/07, Collin Winter <collinwgmail.com> wrote:
[SNIP - Adding test.test_support.TestCase]
>
> So: any objections to making this change?

God no!  I am dying for you to write your replacement for
unittest and
get it into the stdlib!  I am tired of camelCase method
names in all
of my test code.

-Brett
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com