Slow tests

[Martin (gzlist)]

On 17/09/2009, Martin Pool <mbp at canonical.com> wrote:
> 2009/9/18 Robert Collins <robertc at robertcollins.net>:
>> Its handling of comments and docstrings that probably drove Martin's use
>> of the AST. If we're not actually using the word assert anywhere, then
>> I'd just be as simple [and fast:)] as possible.
>
> Yes, I used the AST so that it would be more correct, but this is an
> unreasonably high price to pay for it.  I think using a regexp is
> fine, and if that means that we can't have the word 'assert' at the
> start of a line in a docstring we'll live with it.

Everyone else is running off on the grep route, but could also use the
_ast module. That means Python 2.5 or later, but skipping the source
checking tests on 2.4 wouldn't hurt much. Quick hack reveals it is
somewhat faster:


$ bzr selftest -vs bzrlib.tests.test_source.TestSource.test_no_asserts
running 0 tests...
testing: /usr/bin/bzr
   /usr/lib/python2.5/site-packages/bzrlib
   bzr-2.1dev python-2.5.2 CYGWIN_NT-5.1-1.5.25-0.156-4-2-i686-32bit-WindowsPE

test_source.TestSource.test_no_asserts                           OK    38515ms
test_source.TestSource.test_no_asserts2                          OK    16921ms
test_source.TestSource.test_no_asserts3                          OK     8219ms

----------------------------------------------------------------------
Ran 3 tests in 63.734s

OK


That's the current (old) test using the parser module, then the same
thing using _ast, then with a slightly smarter tree walking function.

Adding --lsprof-tests seems to show that the bulk of the remaining
time is 6.2 seconds to compile 667 things. Still too long, but would
be spread across any new source tests that want an AST - which could
be used to check for a bunch of other stuff mentioned in HACKING.txt
as well. Actually compiling every source file seems reasonable, as
distutils is rather sloppy with syntax problems - though I guess test
coverage is good enough that all files get checked by the suite
anyway.

Martin