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.
