in reply to How to write test scripts depending on DBI

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]
Or make the test conditional on having DBD::Sqlite installed 
#!/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.

Replies are listed 'Best First'.
Re^2: How to write test scripts depending on DBI
by SilasTheMonk (Chaplain) on Oct 05, 2009 at 20:00 UTC

    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.

[reply]

      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.

[reply]

        Thanks for the clarifications. That's much clearer.

        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.
        Well yes those are all fair points. Except that:

        1.) When you install DBI you are only guaranteed to get the drivers that come with DBI. None of those are much use for real work. So what puzzles is why so many machines would have DBI but not "real" (highly subjective term) drivers. The arguments are likely to be different for those that happen to CPAN testers machines (my sample) but I am still surprised at the lack of "real" drivers.

[reply]

In Section Seekers of Perl Wisdom