Re: Packaging and testing a module which requires a database

I've struggled with this exact problem for my recent releases of Class::Tables. Its test requires a working MySQL or SQLite datasource, which is filled up with some sample data to test the module's interface. You can check out the source of my Makefile.PL and test.pl to see how I get the module's build process to configure the test datasource. When developing my test suite, I searched CPAN for DBIx::* modules and borrowed (stole) a lot of ideas from those that had test suites (can't remember exactly which ones). DBD::mysql also has quite an extensive test suite, so you have a few places to start looking.

Here's the very rough outline of what I do for my tests: (I'd also be interested to know if this isn't the Right Way to do it)

MakeFile.PL prompts for database connection info, and then saves it in a ./testconfig/Config.pm file using Data::Dumper. You should provide some mechanism to change the configuration (I use the -s option to MakeFile.PL). You may also want to provide an option to skip the tests here.
test.pl loads the Config.pm file to get the connection information. If the user has decided to skip the tests, or we couldn't connect to the database, you may want to skip_all of your tests. If we could connect, then test.pl empties out all the tables from this database and inserts the test data manually with SQL statements.

That's the basic outline, but I think rather than getting into much more detail, you should look at/steal from other test suites that fit your goals. Hope this helps!

*: Update: Just looked through my browser history: DBIx::FullTextSearch is one of the DBIx:: modules I used as a test template.

blokhead

Comment on Re: Packaging and testing a module which requires a database

Replies are listed 'Best First'.
Re: Re: Packaging and testing a module which requires a database by legLess (Hermit) on Feb 06, 2004 at 18:00 UTC
Thanks for your reply. I've got a Config module that loads from a config file (in YAML, as it should be :-). That's not a bad way to do it. But the more I think about it, it seems like The Right Way is to use some lightweight RAM or filesystem data source. Which I need to implement anyway. The Intermediate Way will likely be chromatic's envinromental variable suggestion.	[reply]