What to test for in a module that returns a DB handle?

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hello monks,

I would like advice on how to write tests for a module I have written that is going onto CPAN. It's the base class for connecting to a CMS and the only method it has is to create and return a database handle.

I don't need to test whether the method will actually return a connection to MySQL; modules that use this one will do that. What I want to do is test the module when it's installing on a system.

Not sure really what to test for though. That my calls to the DBI are correct? Suggestion, please?

So far I have thought of:

1) Use DBD::Mock
(But that seems to be for testing your SQL, how your app handles a DSN error, etc.)

2) Require the user to provide database credentials during installation and actually test that the module can create the dbh.
(This would of course test not only my code but whether their environment can actually run the code ... But is it customary to write a test that requires interaction?)

Thanks for your input.

Comment on What to test for in a module that returns a DB handle?

Replies are listed 'Best First'.
Re: What to test for in a module that returns a DB handle? by Anonymous Monk on Jun 13, 2015 at 07:36 UTC
Test whatever stuff if user provides PERL_DISTNAME_LOGIN and PERL_DISTNAME_PASSWORD, otherwise skip trying to do stuff See http://wiki.cpantesters.org/wiki/CPANAuthorNotes , use prompt of ExtUtils::MakeMaker to gracefully prompt for running interactive tests, it respects $ENV{AUTOMATED_TESTING}	[reply]
Re: What to test for in a module that returns a DB handle? by locked_user sundialsvc4 (Abbot) on Jun 14, 2015 at 17:38 UTC
Many of the DBI modules ... and, I believe, DBI itself ... include some tests within their test-suite which do test connectivity. Those tests are generally defined to be optional. (For instance, I don’t think that the pre-install test-list that is run by the `cpan` command mandatorily executes them, but if you want to run the tests yourself, you can choose to include them.) These tests, IIRC, require that a particular database-name be defined, with a particular user-id and password that has full-privilege to that database. For testing purposes only. And they very-exhaustively test the correct operation of the package. I suppose that the ruling assumption is that “the author of the module did run those tests. (And CPANTS probably does, too.)” Such that individual client sites, realistically speaking, don’t have to do so unless they particularly want to. That seems like a well-balanced compromise to me, and I suggest that you do the same.