Re: Common DBI Driver Test Suite - Requirements - take 2

Am 29.09.2013 um 21:02 schrieb Tim Bunce <[email protected]>:

> Here's an updated Requirements document, tweaked a little based on the feedback.
> 
> 
> Goals:  ("how will we know if this project is or is not a success")
> 
>    G1. driver developers improve their compliance with the DBI API
>        and so improve consistency and portability of code.
>        This is what it's all about!
> 
>    G2. driver developers adopt DBIT as a free test suite with good
>        coverage of the DBI API. This is the pay-back _for_ developers.
> 
>    G3. driver developers write and share reusable generic tests
>        (they'll still need to write their own driver-specific tests).
>        This is the pay-back _from_ developers.
> 
>    G4. end users aren't affected by DBIT evolution causing install failures
>        i.e., DBIT runs as 'author testing', *at least for now*.
>        This is our promise to end users not to ruin their day.
> 
>    G5. works with the widest range of DBI drivers, including non-SQL and
>        proxy drivers.  This is a promise to be inclusive and flexible.
> 
>    G6. enables testing with DBI::PurePerl for pure-perl drivers.
>        This is a promise to support fatpackers and perl6 ;)
> 
>    G7. end users can find the level of DBI API compliance of a driver
>        The test configuration, e.g., what tests to skip, will be data-driven
>        rather than hard-coded logic, and the data will readable via some API.
> 
> 
> Scope:  (the boundaries and deliverables of the project)
> 
>    S1. the DBIT will be a separate distribution.
> 
>    S3. the DBI won't have a mandatory dependency on DBIT,
>        for now at least, driver developers are the priority.
> 
>    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.
>        Those tests could use the DBIT infrastructure.
> 

I don’t find the mail regarding that, but I remembered that my primary
goal is testing the underlying database (I call it SQL::Statement ^^).


> Requirements:
> 
>    R1. be easy for driver developers to adopt,
>        so existing drivers migrate to using it.
> 
>    R2. be easy for driver developers to extend/contribute to,
>        so driver developers contribute to it.
> 
>    R3. work well with cpantesters,
>        so we get good coverage (perhaps extend Test::Database)
> 
>    R4. use get_info as the basis for determining the capabilities
>        of the driver and database. We'll extend get_info as needed.
> 
>    R5. allow tests to be run in parallel, e.g. unique table names.
> 
>    R6. provides tools that drivers can use/extend for themselves.
>        I'm thinking specifically here of the creation of test files
>        with combinations of env vars and other settings.
>        E.g., test DBD::CSV with Text::CSV and Text::CSV_XS
> 
> 
> Tim.
> 

-- 
Jens Rehsack
[email protected]