On Wed, Oct 08, 2008 at 10:17:31AM -0400, Greg Sabino Mullane wrote: > > > It should be fairly easy for willing CPAN testers to setup any database > > they like, and provide some connection information for throwaway tables > > and data (assuming the test script WILL probably drop all tables in > > there and dump its own crap there). > > This seems of dubious usefulness, as the intersection between the number > of CPAN testers that would bother to set this up, and the number of > modules that would make use of it, would be very small.
As far as I know, nothing exists yet for this kind of generic testing. Everyone rolls their own. DBIx::Class for example, relies on three environment variables per database engine, which probably means that most of the database-specific tests are not run because, just like you, I doubt CPANT testers bother to set those variables either. On the other hand, this list is the perfect place to reach CPAN testers if I can come up with a decent implementation for such a scheme. ;-) Being able to automagically setup a database by creating the appropriate temporary files (for sqlite) or using the default credentials (for MySQL and others) or even creating the whole database cluster (as you explained for Pg), and failing that, using a configuration file setup by the tester (only once, for all modules that will make us of this), seems interesting in the long term. Especially if CPAN testers are ready to set this up. If the discussion here can help me come up with a decent interface and help me avoid the obvious problems (I'm no database expert), then I think we can have a nice addition to the Perl test framework. > > After seeing your code, I suppose it could also be somewhat easy to try > > out a few series of basic/default credentials on localhost for engines > > like MySQL and Postgres, and try to setup a test database from there. > > > > Does that sound like an interesting tool to have? > > That sounds more interesting. Thanks for the encouragements (and criticism). :-) > The DBD::Pg strategy is to try and use > DBI_DSN if is defined. Aha! So DBI_DSN is an environment variable I can look at when trying to find a configured database. > Even when defined, it often fails due to permission > issues, so we fall back to creating a brand new database cluster from > scratch, which ensures that we can control all the parameters, paths, and > permissions ourselves. Feel free to crib from the code in the link below. > If I was doing it all over again, I might even jump straight to clean > creation (via initdb) first. > > http://git.postgresql.org/?p=dbdpg.git;a=blob;f=trunk/t/dbdpg_test_setup.pl Thanks for the link. Expect me to bother you with questions when I reach the point of trying to automagically setup a Pg database. :-) I'll try to come up with something for creating test databases on demand. Having some configuration module is a nice fallback for people who secured their database setup or want to have more control on what they provide. -- Philippe Bruhat (BooK) The best thing about being apart is getting together again. (Moral from Groo The Wanderer #39 (Epic))
