FAQ
Hi,

The DBD::mysql driver has some tests that are run against a test
database. By default it tries to connect to a database called 'test',
on localhost port 3306 or using local socket connection depending on
your OS, with the current user and without a password.If the database
'test' is not available, it tries to create one. Then it creates some
tables in the database and removes them after the tests are complete.

Obviously, this fails often. Many times you'd only have libmysqlclient
on your machine if you'd compile DBD::mysql. In 'olden times' you
could only compile against the server headers but this is no longer
the case. And *if* you happen to have a server running locally,
chances are slim the access with the 'default' credentials will
actually work. Because tests do not share global state, every of the
60+ test files tries to set up a database connection on its own, and
then maybe fail. Especially if you don't have a local server running,
this can take some time, because each test tries to connect, and then
times out.

In this section of DBD::DBD -
https://metacpan.org/pod/DBI::DBD#Files-common-to-pure-Perl-and-C-XS-drivers
there is some talk about how drivers should not let database objects
behind and how you should be explicit about what your tests will do.

For DBD::mysql you can specify the database server to test against via
command line switches to Makefile.PL and also via environment
variables.

https://metacpan.org/pod/distribution/DBD-mysql/lib/DBD/mysql/INSTALL.pod#Environment-Variables
https://metacpan.org/pod/distribution/DBD-mysql/lib/DBD/mysql/INSTALL.pod#Configuration

My suggestion would be the following:

1. Only perform tests against a database if one or more switches of
Makefile.PL or environments are set

2. If a database connection can not be successfully created, bail out
with a more or less useful error message

This might mean that where 'database' tests previously tests would be
run, they now don't - but as I tried to explain above I think chances
for successful tests without any configuration are pretty slim
anyways. On the other hand, I think it means that the overall
experience of installing the module might improve, because if there
would be no testing against databases at all we can more easily and
more quickly skip those tests.

Also, if you really want to run tests against a database, it actually
can help you if testing bails out because it fails quickly instead of
running all 60+ test files and having each one trying to set up a
database connection.

As far as I have seen this is more or less similar to how DBD::ODBC does things.

Please let me know if this sounds reasonable or if there would be any
conceivable problems.

--
Michiel

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbi-dev @
categoriesperl
postedFeb 10, '15 at 7:55p
activeFeb 10, '15 at 7:55p
posts1
users1
websitedbi.perl.org

1 user in discussion

Michiel Beijen: 1 post

People

Translate

site design / logo © 2019 Grokbase