SQL configurations in automated testing

[skazat]

I do most of my work on a web app with various choices of a backend (Postgres, MySQL, SQLite, etc) and have a testing suite, mostly used internally, that goes through the relevant tests for all the backends. Most of the code in the program is shared between the backends, but some backends support things that others don't (SQLite and renaming columns, I'm looking at you...) and some implementations have different specs - so I find that helpful.

I'd like to make it easy for someone to run prove on the testing suite, but am wondering if there are any conventions to providing default values for the various configurations of the backends.

For example, I was think of putting the server as, 'localhost', the database as, 'test' the user as, 'test' and the password blank for each of the SQL backends, but I don't know if this is actually a convention.

Right now, the testing suite uses a (small) configuration module to setup various things - including perhaps the defaults I just described above. I was thinking perhaps of also putting some, "Do you *really* want to test this backend" options, so someone who doesn't have one of these backends installed, doesn't have to go through with seeing errors everywhere.

I would like to make this as automated as possible so someone can go through the make, make test and make install process easily. I'm not thinking someone's going to want to configure an SQL server in a config file before running these commands and I can just see the support questions as to why the tests aren't running correctly from people that don't read a README file.

Would perhaps some interaction in the tests be a good idea (somewhat how CPAN asks, on the initial run). Or, should I just put a readme about the various testing options and the people who are interested will care and those who aren't won't?

Looking for experience from wiser people than me. I know many of my questions are more about humans working with computers, but I'm pretty much certain testing is one of the most important parts of a good program. Especially when the program gets up to more than 2 files. I'd like to keep up with good Kweality in my Perl programs, if not to give Perl a (continuing) good name.