Common DBI Driver Test Suite - Requirements - take 2

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.


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.