Maybe I'm missing something, but it seems to me you could just make a module that does the config reading and code the config file location there. When the config moves, you have only one place to change. If you want it to figure out where the config is (from an %ENV variable or looking at the current directory, or whatever), you can do it there there too. Then in each file just has one use line and one sub call to get the config.

Is there something about your situation that doesn't fit this soultion?

Suppose 3 months pass and then some test fails. If the tests are split into multiple test files, it's easier to assess the failure. If you organize tests so that they are run in an order that reflects dependencies, you'll more quickly understand what's wrong. Say the first test is to see if authentication is working and tests that follow assume authentications. You know that if something is wrong with the authentication process, then all the tests that follow (that don't test authentication but that need it) will also fail.

Splitting the tests into multiple test files increases the likelihood that (3 months from now) you'll understand what the test verifies with only a peek at the test code.

Splitting test tests into multiple test files allows you to reuse test logic - you can build a test library. A test that verifies that invalid authentication does not allow access has a lot in common with a test that verifies that valid authentication does allow access.

Splitting tests into multiple files allows you to reduce conditional logic in tests. Suppose you have 3 different user types and you want to verify that they can do what they should and that they can't do what they shouldn't. You might be tempted to write a for loop that loops over the users and in that loop you put logic that will either run a test or not run a test. A better solution is to test each individually.

Gerard Meszaros wrote a wonderful book "xUnit Test Patterns - refactoring test code." Only after my test suite was a year or two old, did I find and appreciate that book.

I'm sure there's Test module(s) (I'm even more sure someone will enlighten me:-) to do it, but whenever I've had to do something similar, I've extracted the common code into a separate file and in each .t file...

do "common.pl";
[download]

HTH ,

I like Test::Class for this.

It's not clear to me where you're going with this. If, for example, you're going to do all this in a single process, then I can see how loading/reading/parsing multiple times is less than desirable. In this case, a separate module where you just ask for the configuration data you need and the module merely loads it when required (i.e., first time data is requested), like others have suggested, would simplify things. If, however, you're hoping to spread your tests out over multiple processes, then either you're forking off each subprocess (where they can inherit the pre-loaded data) or, more likely, they're running completely independently, in which case there's no way to avoid loading the configuration multiple times. In both of these cases, partitioning it off into its own module will just make things easier.

Ok, that's not entirely true - you could set up some shared memory to hold the data so that each test can simply attach to the shared memory to retrieve its data, or have a configuration daemon that you query over sockets or tcp or something instead of reading the file, but I don't think either of these options are seriously viable for this :-)

Thanks -- it's not really necessary for me to fork off a bunch of processes or go to the complication of using shared memory -- I just wanted to simplify (heh) the opening and reading of configuration files by not duplicating work -- but it seems that there isn't a simple way to do it.

Thanks all for your feedback.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

why is that a problem?

It's something I'd like to avoid, just because it's duplication. If there's a workaround, great. If I have to open and read a config file each time for each set of tests, then that's that.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

You can put the duplicated code in a module (as you would in non-test code). Then your test scripts can look like:

use Test::More;
use MyApp::Frob;
use MyApp::Test::Config;

my $cfg = MyApp::Test::Config->cfg;
my $frob = MyApp::Frob->new($cfg->whoToFrob, $cfg->whatToFrob);
ok($frob, "can create a frob");
[download]