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.

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 use My::Testing::Library 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.

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 Test::Harness and 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.

To make sure your test plan counts don't get botched, use skip 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 Test::More) you can also avoid hard coded counts and use done_testing instead.

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 Test::More that won't recognize done_testing 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 Re^9: Do Pure Perl CPAN packages really need to use ExtUtils::Command::MM? and replies for a discussion of some of the issues related to custom test harnesses under ExtUtils::MakeMaker and Module::Build. See also http://search.cpan.org/~evo/Class-MakeMethods-1.01/test.pl.

I really wish I had a less complicated solution for you.

Update: add bracketed clarification in next to last paragraph in response to anonymous monk below.