- What is the best way to let an installing person define the dsn and credentials for a database to connect to for testing? - I am not sure about 'best', but I have used an environment variable, and have a skip_all call if the variable is not set or cannot be used for some other reason. The test uses the credentials when setting up the thing under test when DB credentials are absolutely necessary. If, however, the DB stuff can be mocked out, I do that.
- What is the best way to encapsulate the functionality of reading this information and connecting to that database for providing a dbh to test routines? I want to use this functionality in several test files. Unless this is a test that is specifically addressing the database side of things, I would recommend mocking as much of the DB stuff away as possible. I have been doing a bit of this lately as I touch code written when I was "less experienced" (What frobnitz wrote this?). It seems to me that any time you pull data from the database, you should instead abstract that out to a function call that returns data, and possibly out to its own module. The function can then be mocked in testing, and you only need to test the DB function for what it is explicitly supposed to do. This is a generalization, and should be taken with the right amount of skepticism :-).
- Is there a way to connect only once to a database for all tests in the t-directory of a distribution? A kind of test suite global. No(*). Each .t script is run in its own process.
* - I suppose something could be attempted on some operating systems of opening the DB handle in a wrapper process, setting it up to be passed through some IPC method, and launching your test script once that setup is complete. It seems to me that this would be very fragile and too clever to maintain.