Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

BooK (2612)

BooK
  {book} {at} {cpan.org}
http://paris.mongueurs.net/
Yahoo! ID: philippe_bruhat (Add User, Send Message)

Obfuscation [plover.com]. Pink [axis-of-aevil.net]. HTTP::Proxy [cpan.org]. YEF [yapceurope.org]. Fishnet [perl.org]. Kapow [cpan.org]. Cog's [perl.org] bitch [cpan.org]. Invitation [perl.org]. White [perl.org] Camel [perl.org]. Nuff' said.

Journal of BooK (2612)

Tuesday September 29, 2009
07:04 AM

Test::Database, for CPAN testers

[ #39692 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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
    --
    Waiting on the Road to Eventually, I lost my Place On Line
    • (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