note
ELISHEVA
<p>[mod://Test::Harness] isolates each test suite so you can be sure to have a clean starting environment for each test. If dump/load is not appropriate to your testing situation, as far as I know there isn't (and shouldn't) be a way to share objects between .t files.</p>
<p>What I would recommend instead is rethinking your allocation of tests to files. Put any set-up/tear-down code for tests in a module, i.e. a .pm file. Include that file in your .t files using a <c>use My::Testing::Library</c> statement. This will reduce the length of both test1.t and test2.t (or whatever you call them). Next combine all tests that share a common object into a single test file.</p>
<p>If you need to run only half the tests at any one time, use any arguments your harness will let you pass to tests to control which tests run. However, please note that some of the older implementations of [mod://Test::Harness] and [mod://prove] don't allow you to pass arguments to .t files. You can work around this by setting environment variables, though there might be portability issues involved if you go that route and your software will be distributed on platforms that are not available to you for portability testing. Whatever you do, command line arguments or environment variables, make sure you document them clearly in a place that is easy to find.</p>
<p>To make sure your test plan counts don't get botched, use <c>skip</c> to skip any tests not appropriate to the current test selection. If you can count on a Perl 5.12 installation (or your installation sites are allowed to download the lastest version of [mod://Test::More]) you can also avoid hard coded counts and use <c>done_testing</c> instead.</p>
<p>If you are planning to distribute this module on CPAN [ and want older systems to be able to use your module ] you will need to be especially careful about backwards compatibility issues. For example, older systems have a version of [mod://Test::More] that won't recognize <c>done_testing</c> and will not be able to pass your tests if you rely on that subroutine. Attempts to compensate for the limitations of older installations by writing your own test harness might also run into difficulties - see [id://888863] and replies for a discussion of some of the issues related to custom test harnesses under [mod://ExtUtils::MakeMaker] and [mod://Module::Build]. See also [http://search.cpan.org/~evo/Class-MakeMethods-1.01/test.pl].</p>
<p>I really wish I had a less complicated solution for you. </p>
<p><b>Update:</b> add bracketed clarification in next to last paragraph in response to anonymous monk below.</p>
890108
890108