launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Wed, Dec 8, 2010 at 3:26 PM, Benji York <benji.york@xxxxxxxxxxxxx> wrote:
> On Wed, Dec 8, 2010 at 9:14 AM, Brad Crittenden
> <brad.crittenden@xxxxxxxxxxxxx> wrote:
>> We need to share techniques that we find to speed up tests.
>
> This won't speed up tests but it'll make slow ones easier to see: you
> can combine the -c -vvv and --slow-test options to give a list of tests
> with the slow ones highlighted, like so:
>
>    bin/test -c -vvv --slow-test=2
>
> Which yields output like this: http://i.imgur.com/kZuqO.png
> (note: that test isn't really that slow, I put a sleep in it for effect)

Some other test timing tricks:

If you have a subunit stream (e.g. from ./bin/test -vvv --subunit,
testr or ec2 test), then you can get the slowest tests doing this:
    ./bin/test -vvv --subunit devscripts | subunit-ls --times | awk '{
print $2 " " $1 };' | sort -n

See also http://code.mumak.net/2010/11/boiling-kettles-unit-tests-and-data.html
for how to get even more data.

On the original topic, I'd be wary about pushing for faster tests at a
test-by-test level until the persistence layer work is a bit more
cooked. Some of our simplest and most direct tests don't meet the
criteria in the architectural design metrics, and it would be a shame
to make them less direct or more complicated just to meet an arbitrary
goal that we intend to smash for all tests in one stroke in a few
months from now.

jml