The test scripts are now generally failing because many test machines do not have DBD::SQLite installed.

Add DBD::Sqlite to BUILD_REQUIRES to your Makefile.PL

WriteMakefile(
    ...
    BUILD_REQUIRES => { "DBD::Sqlite" => 0 },
    ...
);
[download]

#!/usr/bin/perl -T

use strict;
use warnings;

use Test::More;

BEGIN {
    eval { require DBD::Sqlite }
        or plan skip_all => "This test requires DBD::Sqlite";
}

...
[download]

From the documentation I cannot see how one would use DBD::Sponge

When you create a DBI::Sponge statement handle, you specify the results fetch* will return:

use DBI qw( );

my $dbh = DBI->connect('dbi:Sponge:');

my $sth = $dbh->prepare('SELECT * FROM Table', {
    NAME =>   [qw( id value )],
    rows => [ [    1, 'foo'  ],
              [    2, 'bar'  ], ],
    RaiseError => 1,
});

$sth->execute();  # Does nothing

while (my $row = $sth->fetch()) {
    print("$row->[0]: $row->[1]\n");
}
[download]

1: foo
2: bar
[download]

It's used to pass values to a sub which expects a statement handle without having to use a database.

Aargh! The first two answers I understand and know how to do. I was more looking for defences and criticisms of them as solutions.

If I understand DBD::Sponge correctly you cannot use a Sponge handle without knowing it is a Sponge. I thought the whole point of DBI is that once you have a DBI handle the perl code by and large does not need to know what the driver is (leaving aside issues of SQL dialect which obviously DBI can do nothing about.) As such I don't see why the Sponge module is in the DBD space let alone shipped with DBI. The same almost applies to DBD::Mock except that I can see some rather specialized applications for that. For example it might be useful to test a module that constructs SQL statements.

I thought the whole point of DBI is that once you have a DBI handle the perl code by and large does not need to know what the driver is

Ideally, yes, but it's overkill to write a database engine that parses and processes INSERT and SELECT statements if your goal is to produce statement handles that read arrays (something very useful, particularly to database drivers).

As such I don't see why the Sponge module is in the DBD space let alone shipped with DBI.

DBD::Sponge is usually used by other database drivers. As a building block for building database drivers, it is fitting for it to be in DBI.

As such I don't see why the Sponge module is in the DBD space

Where else would you put a DBD?

I was more looking for defences and criticisms of them as solutions.

DBD::Sponge: Unless you're testing a module that expects nothing but executed statement handles, not useful. Sorry, I thought I had made that obvious.

DBD::Sqlite: No criticisms, thus my post. It's supported by popular ORMs, so it's excellent if your app/distro uses such an ORM.

Why would DBI be installed on a test machine but not a sensible driver?

Who cares. The installer handles all that for you.

The question makes no sense anyway. A sensible driver for one purpose is not sensible for another. A particular driver that's sensible today won't be sensible tomorrow.

Thanks. That looks genuinely promising; close enough to my DBD::TestVirtual to be affirming. And it is one I really had not heard of. I'll need to print off Test::Database::Tutorial and come back to thread. I even more interested now to see if anyone else has any ideas.