Hopefully, a week after my Test::Database, for CPAN Authors, some CPAN authors have started to use Test::Database. ;-)
Test::Database is fine to test database independence on your local setup, but to really leverage the power of CPAN Testers to fully test your module over all types of setups, it needs to be installed and configured on a sufficient number of tester hosts.
During my YAPC Europe 2009 talk about Test::Database, I invited several CPAN testers to attend. This is a chicken and egg type situation: this is a useful module, but CPAN authors will use it if they know it will be available on a reasinable number of testing hosts. On the other hand, few CPAN tester will bother configuring it if noone's using it anyway.
This post is basically a replay of my YAPC::Europe talk: last week I invited CPAN authors to try out Test::Database, and this week I invite CPAN testers to install and configure Test::Database as part of the toolchain installed on their smokeboxes.
And the documentation contains a nice tutorial, so it shouldn't be too hard.
Re:So what should be the order of precedence?
BooK on 2009-10-06T14:51:18
(Sorry for the late answer...)
I agree that we have overlapping concerns, and that I have probably overlooked some use cases (I was concerned with testing over as many database engines as possible).
Regarding defaults, Test::Database will automatically fallback on any file-based database that is available.
Test::Database is about letting the system owner do all the hard work of configuring databases for us, and just providing what's available. Test::Database only provides the DSN information, but filling the database is up to the test author (or, if I understood correctly, your module). On the other hand, it garantees you'll get the same DSN information between scripts in the same test suite (the mapping algorithm is based on the cwd).
We should probably continue by email, if you're interested.