Order Restored

Ovid on 2003-04-04T00:20:50

By the time you read this, merlyn will probably have passed me (again) as the number one monk on Perlmonks (discounting the site creator and his extra million XP, of course :). This seems a bit more reasonable than my sitting up there as top dog. While I like Perlmonks, too many people equate XP with Perl experience.

In other news, we just hit 2000 tests for our latest project. Unfortunately, the tests were getting to be tough to manage as many of them took so long to run that it was tempting to skip the entire suite altogether (I suspect that some recent test failures were due to this problem). As a result, I wrote a little snippet to better manage tests. (the link is to a version that includes pod documentation)

#!/usr/bin/perl -w
use strict;
use Test::Harness;
use Getopt::Long;

BEGIN { chdir 't' if -d 't' }

my (@exclude,@include);
GetOptions(
   'verbose!'  => \$Test::Harness::verbose,
   'quiet'     => sub { $Test::Harness::verbose = 0 },
   'include=s' => \@include,
   'exclude=s' => \@exclude
);

@include = map { glob } @include;
@exclude = map { glob } @exclude;

my @files = @include;
unless (@files) {
   @files = glob "*.t";
}

my @tests;
foreach my $file ( sort @files ) {
   push @tests => $file unless grep { /\Q$file\E/ } @exclude;
}
runtests( @tests );

---

Long-running tests

dws on 2003-04-04T00:38:46

Out of curiousity, do you have some idea why your tests are taking so long to run? Are some of them doing database access?

Neat script, by the way.

Re:Long-running tests

Ovid on 2003-04-04T00:52:13

Glad you like the script. As for the perfomance problem, try running various combinations of this:

SELECT foo FROM bar WHERE baz LIKE '%quux%'

And do that on huge tables. The LIKE clause negates the use of indices, so I'm not sure how to get around this problem. Unfortunately, due to business requirements, we have this repeatedly. If you have any suggestions ...

Re:Long-running tests

dws on 2003-04-04T01:09:57

Yeah, that case is pathological. Better to move it off to the side and only run it periodically.

Re:Long-running tests

chromatic on 2003-04-04T02:11:00

How about a test-only database, with just a few rows of data copied from the live database? The fewer rows to scan, the less time a search takes.

Re:Long-running tests

runrig on 2003-04-04T02:15:55

Unless you can create some sort of full-text search index, you're stuck. Though, depending on the database, you might be able to do a little something on the dba side of things (defragment empty table space, etc.).

Re:Long-running tests

pdcawley on 2003-04-04T05:40:47

Mock the DBI handle. Check that the right queries are being issued, and return the 'right' data.

Run the customer/acceptance tests against a real database (but they get run once or twice a day rather than all the time so speed is less of an issue).

Test::Verbose

Matts on 2003-04-04T07:00:58

I use Test::Verbose a lot for running tests. It gives you a binary called "tv" which you just pass in the filenames for the tests you want to run. I've asked barrie to add a -q (quiet) mode that means to run the same thing as TEST_VERBOSE=0 would.

I do like the --exclude thing. Hopefully barrie can add something like that too.