Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
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.