Testing Perl Database Interface, Database Drivers, SQL Engines and Components ...

... is a large story of reinventing wheels again and again

Let's see a few examples for each category

DBI is a large distribution including

DBI itself
Several DBD's
a basic SQL engine

So DBI comes along with a lot of tests

for the Database Interface itself using DBD::NullP
for basic driver instantiation tests using DBD::ExampleP

But there're more tests ...

for the proxying DBD DBD::Gofer relying on bundled DBD::DBM
DBD::DBM tests to ensure Gofer doesn't show false positives
DBI::SQL::Nano tests to ensure DBD::DBM understands SQL

... and combinations

whether each test runs with XS or Pure-Perl version of DBI
driver instantiation works through Proxy (bundled DBD::Gofer)
optional SQL engines don't break DBI::DBD::SqlEngine and DBD::DBM

DBI bundled DBI::SQL::Nano has limited capabilties and so limited tests

only one table per query
no functions and no aggregates
no boolean conjunction in where clauses

DBI::DBD::SqlEngine abstracts DBD's without own SQL engine from engine to use

DBI::SQL::Nano
SQL::Statement

Tests in SQL::Statement concentrates on SQL engine processing

DBD::CSV by H. Merijn Brand provides DBI conformance tests for SQL::Statement

DBD::ODBC by Martin Evans has own tests for API conformance checks

DBD::SQLite by Kenichi Ishigaki concentrates more on database operations

This all increases the test effort for everyone writing applications relying on several DBI Drivers or provides DBI addon's

The way out is

DBI::Test

One Distribution to rule them all, One Distribution to find them, One Distribution to bring them all and under testing bind them

to rule them all

because DBI and SQL::Statement will rely on DBI::Test, every module based on either of them can and should use it, too

the team of DBI authors and maintainers currently strongly cooperates to fix found issues in either DBI or a DBD with the DBI Driver authors, which are often the same people

to find them

like Test::Database by Philippe Bruhat DBI::Test helps tests to find suitable datasources

to bring them all

team persist of Peter Rabbitson (ribasushi), H. Merijn Brandt (Tux) and Jens Rehsack (Sno) convinced some DBD maintainers to use it and will continue convince everyone

and under testing bind them

Mentor Tim Bunce watches the activities and helps to make and keep our customers happy

continuous cooperation will be improved by relying on the same test cases

What's to do by any DBD maintainer or author to benefit from DBI::Test

Create and populate the tests for your DBD

use lib 'lib'; # for use DBI::DBD
use DBI::Test::Conf ();
my @gen_tests = DBI::Test::Conf->setup(
AUTHOR_TESTS => 0,
SKIP_FILE => "DBI-TEST.SKIP",
CONTAINED_DBDS => [qw'DBM File']);

AUTHOR_TESTS tell wether to generate the tests in t/ or xt/
SKIP_FILE tells DBI::Test::Conf to generate a file you can include in your MANIFEST.SKIP
CONTAINED_DBDS tells DBI::Test::Conf which DBD's are introduces and thus what generic tests shall be populated

embed tests in Makefile.PL / Build.PL

WriteMakeFile( ...
test => { TESTS => join(' ' =>
't/*.t xt/*.t', # non-populated
@gen_tests), }, # populated
clean => { FILES => join(' ' =>
@gen_tests ), });

From there on, all DBI::Test and DBI::Test's plugins (as DBI and SQL::Statement provided tests are populated and will be run on make test

prepare you're database access

Write a dbi-test.json (with File::ConfigDir the name is more flexible)
Write a DSN Provider like DBI::Test::ns::DSN::Provider::DBD
Set appropriate environment variables

Create a dbi-test.json { "DBI::Test::basic::connect":
["dbi::CSV:",null,null,
{"csv_class":"Text::CSV_XS"}], "DBI::Test::basic::disconnect":
["dbi::CSV:",null,null,
{"csv_class":"Text::CSV_XS"}]
}

Create a DSN Provider package D::T::DBI::DSN::Provider::DBM;
use base "D::T::DSN::Provider::Dir";
# deliver DSN's generic configuration
# for test population
sub dsn_conf { ... }
# deliver DSN for using in run_test
sub get_dsn_creds { ... }

add your own test case

package D::T::C::SQL::Statement::error;
use parent qw(D::T::SQL::Statement::C);
use Data::Dumper;
use Test::More;
use DBI::Test;
# return true when $cfgs are supported
sub supported_variant {
my ($me, $tc, $cfg_pfx, $cfgs,
$dsn_pfx, $dsn, $options) = @_;
... }
# deliver DSN for using in run_test
sub run_test {
my @DB_CREDS = @{$_[1]};
... }

Introduce your test case to DBI::Test

package D::T::SQL::Statement::List;
use strict;
use warnings;
use parent qw(DBI::Test::List);
sub test_cases
{
my $bas = "SQL::Statement::";
map { $bas . $_ } qw(error);
}

want to know more?

use the source, Luke!

This presentation has been created by Jens Rehsack with impress.js and VI Improved.
I'm a freelancer in cologne area.
Questions? rehsack@cpan.org or (more responsive) dbi-dev@perl.org