any opinion on 'make quicktest'?
I run the regression test a lot. I have found that it is often useful to exclude some of the slowest tests for most of the test runs and then do a full test run before I commit changes. Would anyone be opposed to a quicktest target in the Makefile that supports this practice? There are a small number of tests that each take at least 10 seconds to complete. Jeremy Index: Makefile.pre.in =================================================================== RCS file: /cvsroot/python/python/dist/src/Makefile.pre.in,v retrieving revision 1.8 diff -c -r1.8 Makefile.pre.in *** Makefile.pre.in 2001/01/29 20:18:59 1.8 --- Makefile.pre.in 2001/02/01 16:19:37 *************** *** 472,477 **** --- 472,484 ---- -PYTHONPATH= $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) PYTHONPATH= $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) + QUICKTESTOPTS= $(TESTOPTS) -x test_thread test_signal test_strftime \ + test_unicodedata test_re test_sre test_select test_poll + quicktest: all platform + -rm -f $(srcdir)/Lib/test/*.py[co] + -PYTHONPATH= $(TESTPYTHON) $(TESTPROG) $(QUICKTESTOPTS) + PYTHONPATH= $(TESTPYTHON) $(TESTPROG) $(QUICKTESTOPTS) + # Install everything install: altinstall bininstall maninstall
Jeremy Hylton writes:
I run the regression test a lot. I have found that it is often useful to exclude some of the slowest tests for most of the test runs and
I think this would be nice.
In fact, for this, I'd only run the test once and would skip the "rm" command as well. I usually just run the regression test once (but with all modules, to avoid the extra typing). -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
"FLD" == Fred L Drake, <fdrake@acm.org> writes:
FLD> In fact, for this, I'd only run the test once and would skip the FLD> "rm" command as well. I usually just run the regression test FLD> once (but with all modules, to avoid the extra typing). Actually, I think the rm is important. I've spent most of the last month running make test to check the compiler. Jeremy
Jeremy Hylton writes:
Actually, I think the rm is important. I've spent most of the last month running make test to check the compiler.
Yeah, but you're a special case. ;-) That's fine -- it's still much better than running the long version every time. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
"JH" == Jeremy Hylton <jeremy@alum.mit.edu> writes:
JH> I run the regression test a lot. I have found that it is JH> often useful to exclude some of the slowest tests for most of JH> the test runs and then do a full test run before I commit JH> changes. Would anyone be opposed to a quicktest target in the JH> Makefile that supports this practice? There are a small JH> number of tests that each take at least 10 seconds to JH> complete. I'm strongly +1 on this, because I often run the test suite on an Insure'd executable. It takes a looonngg time for even the quick tests. -Barry
On Thu, Feb 01, 2001 at 11:21:30AM -0500, Jeremy Hylton wrote:
Definately +1 here. On BSDI 4.0, which I try to test regularly, test_signal hangs (because of threading bugs in BSDI, nothing Python can solve) and test_select/test_poll either crash right away, or hang as well (same as with test_signal, but could be specific to the box I'm running it on.) So I've been forced to do it by hand. I'm not sure why I didn't automate it yet, but make quicktest would be very welcome :)
+ QUICKTESTOPTS= $(TESTOPTS) -x test_thread test_signal test_strftime \ + test_unicodedata test_re test_sre test_select test_poll
-- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Jeremy Hylton writes:
I run the regression test a lot. I have found that it is often useful to exclude some of the slowest tests for most of the test runs and
I think this would be nice.
In fact, for this, I'd only run the test once and would skip the "rm" command as well. I usually just run the regression test once (but with all modules, to avoid the extra typing). -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
"FLD" == Fred L Drake, <fdrake@acm.org> writes:
FLD> In fact, for this, I'd only run the test once and would skip the FLD> "rm" command as well. I usually just run the regression test FLD> once (but with all modules, to avoid the extra typing). Actually, I think the rm is important. I've spent most of the last month running make test to check the compiler. Jeremy
Jeremy Hylton writes:
Actually, I think the rm is important. I've spent most of the last month running make test to check the compiler.
Yeah, but you're a special case. ;-) That's fine -- it's still much better than running the long version every time. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
"JH" == Jeremy Hylton <jeremy@alum.mit.edu> writes:
JH> I run the regression test a lot. I have found that it is JH> often useful to exclude some of the slowest tests for most of JH> the test runs and then do a full test run before I commit JH> changes. Would anyone be opposed to a quicktest target in the JH> Makefile that supports this practice? There are a small JH> number of tests that each take at least 10 seconds to JH> complete. I'm strongly +1 on this, because I often run the test suite on an Insure'd executable. It takes a looonngg time for even the quick tests. -Barry
On Thu, Feb 01, 2001 at 11:21:30AM -0500, Jeremy Hylton wrote:
Definately +1 here. On BSDI 4.0, which I try to test regularly, test_signal hangs (because of threading bugs in BSDI, nothing Python can solve) and test_select/test_poll either crash right away, or hang as well (same as with test_signal, but could be specific to the box I'm running it on.) So I've been forced to do it by hand. I'm not sure why I didn't automate it yet, but make quicktest would be very welcome :)
+ QUICKTESTOPTS= $(TESTOPTS) -x test_thread test_signal test_strftime \ + test_unicodedata test_re test_sre test_select test_poll
-- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
participants (4)
-
barry＠digicool.com -
Fred L. Drake, Jr. -
Jeremy Hylton -
Thomas Wouters