Re^3: Test::Class and test organization

[xdg]

Could you share some examples of the other dimension in your grid? What I think you're saying is that you have a set of input data that you want to use repetitively in different tests -- but I'm not clear on whether these different tests are classes or subsets of functionality of the classes.

I'm not sure this necessarily calls for Test::Class. What about factoring all the test cases into a helper module:

# t/Data.pm
package t::Data;

our @cases = (
  {
    label => "3 pairs",
    input => ( 'a' .. 'f' ),
  },
  # etc...
);

1;

Create all the separate .t files using that package for input data:

# t/42_somefunctionality.t
use Test::More; # no plan here!
use t::Data;

my $tests_per_case = 13;

plan tests => $test_per_case * @t::Data::cases;

for my $case ( @t::Data::cases ) {
  # 13 tests here for each case
}

In the Test::Class paradigm, I think this would done with a superclass and the individual test classes would inherit from it:

# t/DBM/Deep/Test.pm
package t::DBM::Deep::Test;
use base 'Test::Class';
use Test::More;

my @cases = (
  # all test data here
);

sub startup :Test(startup) {
  my $self = shift;
  $self->{cases} = \@cases;
}

1;

# t/DBM/Deep/Feature1.pm
use base 't::DBM::Deep::Test';
use Test::More;

sub a_simple_test :Tests {
  my $self = shift;
  for my $c ( @{ $self->{cases} } ) {
    # tests here
  }
}

1;

# runtests.t

use t::DBM::Deep::Feature1;
use t::DBM::Deep::Feature2;
# etc...

Test::Class->runtests();

This is similar to how something like CGI::Application recommends using an application-wide superclass to provide the common DBI connection and security but individual subclasses for different parts of the application. I'm not sure exactly how to get the plan right, though.

For another approach (similar to the first one I mentioned), you might want to look at how I structured the tests for Pod::WikiDoc. I put all the test cases as individual files in subdirectories, and then my *.t files called on some fixture code to run a callback function on each test case in a directory. (This is almost exactly what Test::Base is designed to do, but I wanted to avoid that dependency.)

Is any of this helpful for what you're trying to do?