On Thu, Sep 26, 2013 at 05:55:56PM +0100, Martin J. Evans wrote: > On 25/09/13 17:28, Tim Bunce wrote: > > > > G2. driver developers adopt DBIT as a free test suite with good > > coverage of the DBI API. This is the pay-back _for_ developers. > > I think one thing many DBD test suites could benefit from is wrappers > around many of the DBI methods that wrap that method in tests e.g., > when execute is called, did it return undef, a true value (0E0 or a > number > 0) or -1 depending on whether it is a select statement or > not. If test suites were converted to use those I'm sure we'd find > quite a few issues in DBDs but still using existing test code.
I don't follow you here Martin. DBIT will implement detailed testing for the return value of execute. > > G9. end users can find the level of DBI API compliance of a driver > > i.e., by looking at the test configuration for the driver > > to see what areas of functionality are configured to be skipped. > > This in particular is something I'd like to see and expand on. > > [...] > a capability system beyond what get_info provides. get_info is pretty > much ODBC's SQLGetInfo and few drivers beyond DBD::ODBC really support > it that well. I'm expecting that one of the side-effects of DBIT will be a great improvement in support for get_info by drivers. That'll be a win for all. It's also worth noting that we can define our own meanings for certain values passed to get_info. With surprising foresight, sometime around 1998 I think, I arranged for the get_info values 9000 thru 9999 to be reserved for the Perl DBI in the ISO standard registry: Registry of Values for the SQL Standard (ANSI X3.135 and ISO/IEC 9075) With especial attention to values related to SQL/CLI ([ANSI/]ISO/IEC 9075-3) I actually reserved value ranges for just about all of the SQL CLI functions. http://www.nntp.perl.org/group/perl.dbi.users/2007/04/msg31285.html > [...] > > If I put my mind to it (and looked at my code from years ago when I > was involved in writing to multiple DBDs from the same application) I > could proably come up with a much longer list - Peter probably could > too. When the time comes we'll probably need one :) > I know this is not DBIT as such and you might see it as a distraction (if you > do, ignore) but I think it would be worth while. Very. I think it's important. > > R3. work well with cpantesters, > > so we get good coverage (perhaps extend Test::Database) > > As a side note, I as going to add support to Test::Database for > DBD::ODBC because I thought it might get me more smokers actually > running the tests. Then I discovered it needed create database > support, and that was not going to happen with ODBC as each database > has totally different syntax for that and some databases need very > high level permissions to create a database. As I mentioned elsewhere, I suspect we'll want to extend or fork Test::Database to bend it to our needs. > These seem like worthwhile goals. Whether I can be of any help, I > don't know, but I'll at least try and keep up with the discussion and > provide any useful feedback. Thanks Martin. Tim.