Am 25.09.2013 um 19:27 schrieb Tim Bunce <tim.bu...@pobox.com>: > On Wed, Sep 25, 2013 at 07:02:07PM +0200, H.Merijn Brand wrote: >> On Wed, 25 Sep 2013 17:28:04 +0100, Tim Bunce <tim.bu...@pobox.com> >> wrote: >> >>> 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. >> >> I have a hard time parsing that. > > Drivers have various limitations, things they don't, or can't, support. > It would be unreasonable for them to fail DBIT for those reasons. > So there needs to be a way for those drivers to tell DBIT that > certain tests should be skipped.
Riba put that into a R4: It should be possible to configure which test(case) should be run and which not. This should be possible in a manner which avoids asking cpantesters 100 y/n questions ^^ Maybe this belongs to that point (Riba should be able to explain better). For me, a G10 is interesting (handling SQL::Statement as a DBD) G10: Provide tools/infrastructure to combines several test cases in particular order into tests to allow workflows being tested and stress tests by looping can be performed. > And not just drivers. Things like proxies will need to influence > what's expected to work. This is a key area. > > What G9 is trying to express is that that information (which tests to > skip) is useful for end users, and probably applications as well. > So we should aim to design the system in a way that make that > information available in a useful way. > > Some of that might end up being handled by $dbh->get_info() but there's > bound to be some that isn't. > > >>> S4. DBIT is not meant to test the underlying database. >>> If a driver implements a database itself then it'll >>> need it's own tests to provide good coverage of that. >> >> DBIT will offer the interface to test the underlying database. What is >> important here, as DBIT will offer the possibility to test under >> different circumstances (like with SQL::Nano or under DBI::Proxy) >> without having to rewrite all tests over and over again. >> These test will reside in the test suite of the DBD, not in the test >> suite of DBIT > > Yes. Or, for drivers that want to share tests, those tests could live in > modules installed by a distro that the driver declares it's dependant on. I would prefer the "distributed separately" way. It doesn't have to be dozen of independent distributions, there could be a few thematically grouped ones. Like some for ANSI SQL, some for proxy specific ones (like spreading some requests to see how the scaling is?), …) Cheers -- Jens Rehsack pkgsrc, Perl5 rehs...@cpan.org