My initial input would be: Ensure that we have proper goals!!!
Is this going to be a DBI conformance test or a driver test suite? I belive those are two different (but not incompatible) goals. A conformance test would be more simple, in that it would test the interface to the driver not necessarily that it's functioning correctly. It would and determine which DBI features the driver supplies vs what DBI allows. Ideally, this would be updated every time a new feature is added to DBI and would produce a report showing which features were implemented by the driver, which by DBI (e.g. the default DBI implementation of array handling vs. the driver implementing it in a "better" fashion). and which are not implemented. A DBD Driver test, in my terms, would be something that reads and writes the data to the database and VERIFIES that it's getting what is expected. In my experience, with DBD::ODBC, this takes a bit of effort. Does this driver supply SQL_INTEGER, SQL_SMALLINT, etc? DBD::ODBC uses a primitive method to work this out and there are probably much better approaches. That said: DBD::ODBC tests, for the most part, pass against Access, SQL Server, DB2 and Oracle (and, when no DBI_DSN is set, which is important for any automated builds). The "Driver" test would, IMHO, be VERY dependant upon the conformance tests, to know what to test and to know how to approach inserts, deletes, etc. I, actually, think the "Driver" test would be more useful for Driver writers and the conformance test more useful for end-users -- and both would be valuable, but I think we should define the goals first. I think I'm not sure which direction this is going. I'm an advocate of covering both "conformance" and "performance" -- but I think those goals should be spelled out first. Just my initial thought. An intended SCOPE would be nice for those of us who would like to contribute, but don't have a lot of time to do it. Jeff
