http://qs321.pair.com?node_id=746583

Hue-Bond has asked for the wisdom of the Perl Monks concerning the following question:

Monks,

I'm consistently using prove -s to run my tests in a random fashion. Some of them interact with a database, and currently I'm resetting the schema and data by hand before running the test suite.

Is there a way to tell prove to run a specific program before running the tests, so the database cleanup can be automated? Or else, what's the standard procedure for doing this?

--
David Serrano

Replies are listed 'Best First'.
Re: Executing something before all tests using 'prove -s'
by ELISHEVA (Prior) on Feb 26, 2009 at 16:43 UTC
    prove is a wrapper around App::Prove. The easy way to do start-up code followed by shuffed tests is to write your own "prove" script that runs the start-up code and then creates and runs an App::Prove instance. You can also add tear-down code this way:

    (Note: this is meant as pseudocode - please ignore typos)

    use strict; use warninges; use App::Prove; #put set-up code here my $oProve = App::Prove->new; $oProve->process_args(@ARGV); my $iExit = $oProve->run ? 0 : 1; #put tear-down code here #and we're done exit($iExit);

    Best, beth

Re: Executing something before all tests using 'prove -s'
by tirwhan (Abbot) on Feb 26, 2009 at 16:28 UTC

    I usually put all my cleanup code into an END block within the appropriate test file. That way, even if the test is interrupted/aborted for some reason, the cleanup code usually runs and I leave a clean environment.

    This becomes a hassle if you set up stuff in one .t file that you depend on in another, but I avoid that (and since you're saying you randomize the execution order of your tests, it seems so do you).

    If you really want to clean up before your tests run and not after (in which case I'd be interested to know why) you could put it into a BEGIN block of the relevant test.


    All dogma is stupid.
Re: Executing something before all tests using 'prove -s'
by Corion (Patriarch) on Feb 26, 2009 at 17:46 UTC

    Personally, I use :memory: databases with DBD::SQLite or I copy canned SQLite database files for every test. That way, I don't have to reset the database even when zeroing in on a bug by running a (set of) test repeatedly.