On Tue, Oct 01, 2013 at 04:49:30PM +0200, Jens Rehsack wrote:
> [...]
Thanks for the Jens. Very helpful.
Forget my earlier proposal. This is a reboot, including input from
discussions on irc.
In thinking about this part of DBIT I tried to isolate the various
"dimensions" of variants. I came up with four:
Env vars that affect the DBI (DBI_PUREPERL, DBI_AUTOPROXY etc)
|
`- The available DBDs (eg Test::Database->list_drivers("available"))
|
`- Env vars that affect the DBD (via DBD specific config)
|
`- Connection attributes (via DBD specific config)
The range of variants for each is affected by the current values of the
items above. E.g., some drivers can't be used if DBI_PUREPERL is true.
The first three can be used to generate variant test files.
(Let's assume for now that testing variants of connection attributes is
best implemented by a given *.t file re-running tests with various
connection attributes. So since it's within the .t file it's out of
scope for this discussion.)
So we're left with three levels: env-vars, DBD, env-vars.
Now,it turns out that if you use a DSN with no driver, i.e. "dbi::",
then the DBI will use the DBI_DRIVER env var to determine the driver.
So now we have three levels: env-vars, env-var, env-vars.
That suggests that there should be a nice generic approach
write_variants(
test_cases => {
foo => ..., # file name or module name or code or similar
bar => ...,
...
},
level_providers => [
sub {
return hash of key => settings-object pairs
},
sub {
return hash of key => settings-object pairs
},
sub {
return hash of key => settings-object pairs
},
...
],
)
write_variants would call the first provider sub and then call the next
for each element returned by the first etc., for all the levels.
Each sub would be passed what the current higher levels had returned
and return the appropriate variant settings for that context.
The 'settings-object' is just a way to abstract out different kinds of
settings and how they get translated to code to execute before and after
the test.
It seems that the only kind of setting we'd need is an environment
variable setting. That would simple translate to $ENV{...}=...;
(plus a delete $ENV{...} on VMS where env vars are persistant).
The variants would be written into a directory tree (avoiding the need
to use single character prefixes). The result might look something like:
t/
plain/
csv/
sql_nano/
foo.t
sql_statement/
foo.t
bar.t
SQLite/
foo.t
bar.t
gofer/
csv/
sql_nano/
foo.t
sql_statement/
foo.t
bar.t
SQLite/
foo.t
bar.t
etc.
Obviously Test::MakeVariantTestFiles is just a low-level part of an
overall system but I think it has value as a stand-alone disto
(once it has matured).
The next level above that would be a module that gathers config
info and calls write_variants(). Before we get into details about that,
does the above seem like a workable foundation?
Tim.
