in reply to Re^2: How Many Modules Is Too Many?
in thread How Many Modules Is Too Many?

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.

Replies are listed 'Best First'.
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]

In Section Meditations