Hi all,
I currently stuck hacking on matching test cases for deriving
test variants. Think as reason about DBI's test cases like
redo'ing all tests using DBI::PurePerl - but only some through
Gofer proxy and a handful with built-in DBI::SQL::Nano vs.
SQL::Statement (when having SQL::Statement)...
Other reason is to run DBI::Test self-test through the bundled
DBI::Mock and through DBI (default attributes test etc.).
Here is a roughly config set:
(
default => {
category => "mock",
cat_abbrev => "m",
abbrev => "b",
init_stub => qq(\$ENV{DBI_MOCK} = 1;),
match => { namespace => [""], },
name => "Unmodified Test",
},
# next stuff might be moved to DBI::Test::DBI::Conf
dbi_pp => {
category => "dbi",
cat_abbrev => "z",
abbrev => "p", # use DBI::PurePerl
init_stub => qq(\$ENV{DBI_PUREPERL}=1;),
match => "...",
name => "DBI PurePerl",
},
dbi_gofer => {
category => "dbi",
cat_abbrev => "z",
abbrev => "g", # use DBI::PurePerl
init_stub => qq(\$ENV{DBI_GOFER ...}=1;),
match => "...",
name => "DBI PurePerl",
},
# next stuff might be moved to DBI::Test::SQL::Statement::Conf
sql_nano => {
category => "sql::statement / dbi",
cat_abbrev => "s",
abbrev => "n",
init_stub => qq(\$ENV{DBI_SQL_NANO}=1;),
match => {
general => qq(\$ENV{DBI.pm} =~ m|/|),
name_space => [qw(DBI)], # DBD::CVS might hook here ...
name => "...",
},
name => "using DBI SQL::Nano",
},
);
The keys of the config hash are intended for hooking from additional
distributions (DBD::CSV, DBD::Sys, DBD::ODBC ...) and hack some flags
from configuration files.
Why is reducing test variants important? Because size matters! With
12 test variants, we'll create up to 2^12 (2 for DBI::Test, 4 for DBI,
optionally DBI::Proxy and/or DBD::Multiplex, up to 4 on SQL::Statement)
combinations of each test. When Test::Database introduce some more
variants - we'll might have 15, and I'm pretty sure, the count will
grow quickly. Running the 150 basic test cases of DBI::Test, DBI and
SQL::Statement in addition to those of DBD::CSV when instaling DBD::CSV,
there will be 819200 test run. That might take some time, even when
they can be parallelized ...
We also have to think about opening a door for Test::Database features
like creating DSN's for testing (DBD::DBM and DBD::CSV currently use
competing (and of course) incompatible own code for that.
While this is discussed and hopefully some cute little ideas follow,
I will work on extracting the plugin namespace (DBI::Test(.*)::Conf) ;)
Cheers
--
Jens Rehsack
