It doesn't on it's own, it runs the tests in whatever test classes you have loaded. So if you have two test classes named App::Test::Foo and App::Test::Bar, then you can run them together...
use App::Test::Foo; use App::Test::Bar; Test::Class->runtests;
In this case they will not be run independently, they will be run in the same interpreter, and I don't think the order they get run in (App::Test::Foo first or App::Test::Bar first) is defined.
If you want them to run independently, you still have to create independent test scripts for them...
# Foo.t use App::Test::Foo; Test::Class->runtests; # Bar.t use App::Test::Bar; Test::Class->runtests;
Generally I don't think of Test::Class as a replacement for traditional *.t, but as a helper for them. It's a great help if you have things like unit tests where you have to setup fixtures first and tear them down after the testing, or if you have a bunch of similar classes that need to have their common features tested as well as their own individual unit tests.
| We're not surrounded, we're in a target-rich environment! |
|---|
In reply to Re^2: Stupid, but fun, ideas in testing
by jasonk
in thread Stupid, but fun, ideas in testing
by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |