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
