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)

Friday December 05, 2008
04:46 AM

Saving Test Runs

[ #38032 ]

I don't have the new version up on Github yet, but App::Prove::History is coming along nicely. I've committed a few changes to Test::Harness to make this work (primarily to pass a TAP::Parser instance along), so even if I post to Github, you wouldn't be able to test it without checking the latest Test::Harness out of Subversion.

I hope to have it on Github this weekend, but it won't go to the CPAN until there is an official Test::Harness release supporting the features I need (something I've not been pressing for because stability of Test::Harness is far more important than my work, but maybe a developer release is in order).

One problem I've already been hit with repeatedly is the evolving underlying schema. I have several changes in mind, but I won't allow this to hold up an alpha release. I think what I need to do is use DBIx::Migration to handle the changes, make it easier to specify an alternate database (PostgresQL or MySQL instead of SQLIte, for example), and maybe write some "cookbook" examples of how to upgrade a database without losing data. Still, making this code properly database independent might mean switching to an ORM and I'm reluctant to add that overhead to test runs.

I also need to write some cookbook examples of SQL to read the database from as I haven't provided a clear API for it. I've now documented the schema, but I may need to provide views and deprecation schedules to handle the schema evolution. It's one thing to provide code for the massses. It's another thing to provide data.

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.
  • I'm quite excited about this. I got turned on to this idea through Smolder, but Smolder has been a heavier weight solution that I was prepared to deploy, but this seems simple enough that it might actually get used.
  • I use the following perlall-maketest and symlinked perlall-makeinstall simple script, and store its results in t/$version/ as simple test files for most of my modules.
    This is much better than relying on the cpantesters results.
    I do this in most of my vmware machines.
    d is for debug, -nt for non-threaded builds.

    $ cat ~/bin/perlall-maketest
    bad="5.00558 5.8.7 "
    export perlall="5.6.0 5.6.1 5.6.2 5.8.0 5.8.1 5.8.2 5.8.3 5.8.4 5.8.5 5.8.6 5.8.8 5.8.9 5.8.9d 5.9.5 5.10.0 5.10.0d 5.10.0-nt 5.10.