On Wed, Jan 23, 2013 at 10:07:01AM +0100, Jens Rehsack wrote:
> On 22.01.13 23:42, Tim Bunce wrote:
>
> >One of my biggest regrets about the implementation of the DBI is that I
> >didn't create a separate test suite that could be reused by driver authors.
> >
> >So each driver has only it's own set of tests that are really only
> >testing the authors interpretation of the barely-specified behavior.
> >
> >I'd *love* to see that error fixed so all drivers authors could make use
> >of, and contribute to, a common DBI driver test suite.
>
> You suggest a DBI::Test suite which is a separate module and is
> required by DBI? This completely different to previous statements
> where DBI should have no additional dependencies ...
I can see lots of ways to structure a reuable test suite.
At its simplest it could be some *.t files in the DBI distro that get
installed alongside the .pm's when the DBI is installed. Plus a module
that provides an interface for running tests. That's probably too
simplistic though.
It could also be a separate distro. (I don't have a problem with an
extra DBI dependency on a distro that would itself not have further
significant dependencies.) I can see arguments to have the DBI depend on
it or it to depend on the DBI.
Before we go much further we need answers to questions like...
Would drivers always run these tests as part of their test suite?
Or would only driver developers run them?
Or would they run only if the optional "DBI driver test" distro was installed?
The answer to that probably depends on what we would we like to happen
when an added/updated test causes a failure for a driver. That
presumably indicates the discovery of a bug or incompatibility in the
driver, but should that stop people installing the driver? Probably not.
I can see a period of evolution where the test suite grows and matures
and where driver authors get more comfortable using it and start to rely
on it more. Then they may shift from using it as a developer-only test
to running it as part of the main test suite.
So the design should be driven by the needs of driver authors and allow
for a range of use-cases.
Let's try to sketch out a test file:
use Test::More;
eval { require DBI::DBD::Test } or plan skip_all => "DBI::DBD::Test not
installed";
my $dbdt = DBI::DBD::Test->new('dbi:CSV:...'); # returns a
DBI::DBD::Test::CSV object
$dbdt->run_all_test_sets; # test sets (eg 'transactions') determined by
get_info()
done_testing();
The DBI::DBD::Test::CSV class would be supplied by DBD::CSV and would
inherit from DBI::DBD::Test::Base. It would, ideally, be empty, but
there are bound to be things that need to be specified per-driver
(creating suitable test tables, for example).
On a related note, I can see this being a great motivation for drivers
to expand the values supported by get_info(), since that should be used
to drive much of the testing.
> Let's discuss this as Merijn suggested at Perl QA hackathon.
Great.
Tim.
