On Thu, Jan 22, 2004 at 02:02:45PM -0500, Jeff Urlwin wrote: > 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.
Ultimately both, I hope, though its initial goal is a very thorough DBI conformance test. Doing that would naturally provide much of the framework for a driver test suite. I would anticipate most driver test suites being greatly reduced to just run the DBI::Test tests and then run their own set of extra tests for driver specific features. I'm assuming here that the DBI::Test suite will have absorbed non-driver specific tests from the existing drivers and end up being a superset of those tests. > A conformance test > would be more simple, in that it would test the interface to the driver not > necessarily that it's functioning correctly. Er, I don't understand that statement. > 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. The concept of a report would be handy (I'm thinking in terms of which groups of tests were skipped due to the driver not supporting certain features), but I care less about how a driver supports something so long as it does - even if it's just letting the DBI look after it, like execute_array(). > 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). Your DBD::ODBC tests certainly have much good experience to offer. > 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. What do you mean by "how to approach inserts ..."? > 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. Goal: I want it all, and I want it now ;-) > 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. I expect your DBD::ODBC tests will provide valuable input to Tom's design. Tim.
