Re^2: How Many Modules Is Too Many?

The second is startup speed, which doesn't sound like a bit problem when you're doing a mod_perl app, unless you're heavy into unit tests, in which case the startup hit for pulling in several tens or hundreds of modules bites you every time you execute a .t file. And when you have several hundred tests (a good thing), the additional startup can add minutes to a full test run (a bad thing).

This problem can (as I'm sure you know :-) be mitigated by building and tearing down your own test fixtures in a single test script rather that using lots of different *.t scripts to isolate your tests.

I'd probably look towards optimising the test suite before I add the extra overhead of rewriting / inlining modules.

Comment on Re^2: How Many Modules Is Too Many?

Replies are listed 'Best First'.
Re: Re^2: How Many Modules Is Too Many? by dws (Chancellor) on May 31, 2004 at 18:55 UTC
This problem can (as I'm sure you know :-) be mitigated by building and tearing down your own test fixtures in a single test script rather that using lots of different *.t scripts to isolate your tests. Many of our .t files already have over a hundred individual tests (i.e., `ok()` tests). Each .t does specific setup and teardown, and many use `END {}` blocks to do useful things like destroy temporary database objects that were inserted for purposes of testing, and which shouldn't be there by the time the next bunch of tests runs. Combining these tests would be possible, but only at the expense of a lot of work. We're getting more mileage by attacking bloat first.	[reply] [d/l] [select]
Re^4: How Many Modules Is Too Many? by adrianh (Chancellor) on May 31, 2004 at 22:05 UTC
Each .t does specific setup and teardown, and many use END {} blocks to do useful things like destroy temporary database objects that were inserted for purposes of testing, and which shouldn't be there by the time the next bunch of tests runs. Doing this sort of thing for large test suites ended up with me writing Test::Class. It may or may not prove useful to you :-) Combining these tests would be possible, but only at the expense of a lot of work. We're getting more mileage by attacking bloat first. Whatever works. Refactoring a large test suite can certainly be a huge job (having had to do it a few times in the past).	[reply]