Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday April 03, 2003
07:20 PM

Order Restored

[ #11430 ]

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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • 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.

    • 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 ...

      • Yeah, that case is pathological. Better to move it off to the side and only run it periodically.
      • 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.

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