in reply to organizing/ running non-module related tests

I think no. :) If (like me) you haven't used MM yet, I think it would make more sense to learn it in a context of actually putting together a perl module for distribution, since that is what MM was created to do, primarily, and its man page includes lots of details and external references about things that apply only to porting, building and installing perl modules.

But you're talking about a database normalize/port task, which is rather different, and depends primarily on the database engine(s) at each end of the porting process, and on the (theoretical and actual) specs for the database schema you're dealing with.

You could probably find useful things in the "Test::*" namespace on CPAN, but it's not clear to me that ExtUtils::MakeMaker itself, as a whole, gives you much of a direct and relevant head-start.

update (forgot to mention): I don't understand why you would expect "a wrapper full of system calls" to be a sensible alternative. Wouldn't you be using perl/DBI to pull data out of the legacy db, maybe store it to appropriate (tab- or comma-delimited value) files, analyze the content of each table, and build a modified set of files for loading into the new db? (Of course, upon creating the properly normalized/ported data for each target table, you'd use your db's native import tool to load them.) Maybe some unix tools (cut/sort/uniq) could speed things up a bit for large quantities of data -- that's a judgment call that can't be made based on what you've told us.

  • Comment on Re: organizing/ running non-module related tests

Replies are listed 'Best First'.
Re^2: organizing/ running non-module related tests
by geektron (Curate) on Sep 20, 2005 at 18:55 UTC
    hrm ... maybe more detail would have helped.

    the tests are similar to what goes on in a module distro. i have a t/ directory that's filling up with DBI-based scripts.

    what i'm looking for is an alternative to running each test (or each step of the migration) by hand. the "wrapper" would basically be something like: 

    system( 'my/dir/01_step1.pl' );
system( 'my/dir/01_step2.pl' );
system( 'my/dir/01_step3.pl' );

    [download]
    which looks an *aweful* lot like a  make target to me.

    the alternative is:  [ mybox ] --> ./01_step1.pl ad nauseam.

    and it's one DB to another .. so there's no real need for files ....

[reply]
[d/l]
[select]
      If that's all you're doing, it's not such a big thing to roll on your own: 
      my @tests = sort <my/dir/*.pl>;  #update: need to sort the glob list
my $return = my $testid = 0;
while ( $return == 0 ) {
    warn "Running $tests[$testid]...\n";
    $return = system( $tests[$testid++] );
}

      [download]
      But learning to use MM is bound to be a good thing anyway, so why ask us whether you should do it?

      update: if your scripts are actually moving data, then of course you'll need to prefix that loop with whatever steps are needed to clear out the destination db before the loop starts -- unless the first script in your list takes care of that.

[reply]
[d/l]
        each script clears out the relevant tables. because of foreign key constraints and such, i need to clean tables backwards, but i have that under control.

        i'm asking if it's the right tool for the job, and as diotalevi pointed out, Test::Harness may in fact be better suited for what i'm trying to do.

[reply]

In Section Seekers of Perl Wisdom