Re^2: organizing/ running non-module related tests

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

Comment on Re^2: organizing/ running non-module related tests Select or Download Code

Replies are listed 'Best First'.
Re^3: organizing/ running non-module related tests by graff (Chancellor) on Sep 20, 2005 at 19:10 UTC
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]
Re^4: organizing/ running non-module related tests by geektron (Curate) on Sep 20, 2005 at 19:39 UTC
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]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks