Test::Database, for CPAN testers

BooK on 2009-09-29T12:04:29

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.


So what should be the order of precedence?

jjn1056 on 2009-09-29T13:21:36

For example, in my Test::DBIx::Class module, which is a tool to ease DBIC testing, you can specify a target database type and if you leave the connect info blank, I will try to automatically deploy a database (either mysql or postgresql) to a temporary area. If none of these are available, I fall back to SQLite.

So, ideally if you are testing, I should first look for this system, and if it's not setup, fall back to sqlite?

Seems like we have some overlapping concerns and might be valuable to collaborate a bit. My stuff is at http://search.cpan.org/dist/Test-DBIx-Class/ and I am currently working on supporting mysql replication. Let me know what you think. At the very least I think I want to use your framework to help with the 'default' mode.

john

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.