On Thu, Jun 24, 2004 at 09:10:09PM +0100, Tony Bowden wrote: > On Thu, Jun 24, 2004 at 02:59:30PM -0400, Andrew Pimlott wrote: > > I see this more as a limitation than a feature. It seems to mean that > > - You need to use the same setup/teardown for all your tests. > > Those that need different things aren't testing the same thing and > should move to a different class.
What about running the same tests with different sample data (so different setup/teardown)? I suppose you could create a sub-class for each data set, but that seems like busy-work. (Unless you can create all those sub-classes automatically from the data....) > > - You're restricted to one test == one method, so you can't paramatrize > > your tests by data (eg, second example below). > > I'm not sure what you mean here. You can have lots of tests in a single > method. And subclasses can add their own extra tests to the parent's > tests. But (I thought) the idea was that every test needs the same setup. If they're all in one method, they won't get that. Also, if you add lots of tests in a single method, (again as I understand) they will stop after the first failure, which is not ideal if the rest of the tests can still run. > > - You don't have much control (correct me if I'm wrong) about the order > > of tests, or the relationship between tests, eg you can't say "if this > > test fails, skip these others". This is straightforward in > > Test::More's simple procedural style. > > You can group dependant tests into one method and have the method return > or die at any point... As above, they won't all get the setup/teardown. > The big gain for me with Test::Class is inheritable tests. I see. Andrew
