> > 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.
Never mind. I was thinking that the conformance test would be more to show what a driver provided and what it lacked (i.e. it doesn't implement get_info(), but does array_xxx(). I think the conformance test is important to driver writers (and I think Dean echoed this...) and the test suite that verifies correct functionality is valuable to both users and driver writers. > > > 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(). As a driver writer, though, it would be nice to have a "nag" that tells me I need to do something with execute_array() (well, er, I have plenty of reminders for that one :) > > > 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 ..."? Actually, it's more how to approach creating the temp table (getting the DBMS specific sql type name for a given type), so that you *can* insert. > > > 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 ;-) Good! > > > 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. I hope so. If nothing else, to see some of the things that I had to deal with. Some drivers don't report support for SQL_INTEGER, but do support SQL_SMALLINT because their integers do not reach the range of the ODBC spec. I suspect that since it seems that some people are using DBD::ODBC to get type info from their DB (thanks Steffan!), I suspect that issue will be perpetuated. Regards, Jeff
