note
adrianh
<blockquote><em>The problem is that I have classes that have waaaay more functionality than can be tested in one file. So, the recommended organisation of Foo::Bar::Test testing Foo::Bar isn't going to work.</em></blockquote>
<p>Yes. I need to explain that better in the documentation. For small simple classes it works well, but if you have multiple fixtures multiple classes make excellent sense.</p>
<blockquote><em> How does the plan get set in these instances? I can run planless, but I'd prefer not to.</em></blockquote>
<p>It should "just work". runtests() will tot up the number of expected tests in both objects and output an appropriate plan. The key is to just call runtests() the once.</p>
<p>Also Test::Class explicitly checks the number of tests executed for each test method - so even without a plan you'll get a test failure generated by Test::Class if you run to many / few tests. Since this is happening at the method level this is actually safer than a global plan :-)</p>
<blockquote><em> Is this a sane use of Test::Class? My only exposure to xUnit has been Rails and the tests I wrote there were variations of the stock test, not anything complex.</em></blockquote>
<p>What I'd do normally is have a separate subclass for each fixture. So in Test::Class I'd do something like:</p>
<code>
{ package Test::Floober;
use base 'Test::Class';
use Test::More;
sub setup_fixture : Test( setup ) {
my $self = shift;
@$self{'foo', 'bar'} = ( $self->foo, $self->bar );
}
sub foo_and_bar_exist : Test(2) {
my $self = shift;
my ($foo, $bar) = @$self{'foo', 'bar'};
ok( $foo, "foo is $foo");
ok( $bar, "bar is $bar");
}
__PACKAGE__->SKIP_CLASS( 1 ); # prevent abstract class running
}
{ package Test::Floober::FirstFixture;
use base 'Test::Floober';
sub foo { 2 };
sub bar { 5 };
}
{ package Test::Floober::SecondFixture;
use base 'Test::Floober';
sub foo { 'abcd' };
sub bar { [ 2..5 ] };
}
Test::Class->runtests;
</code>
<p>Not that there is anything wrong with your way TIMTOWTDI and all that :-)</p>
538194
538194