Am 29.09.2013 um 21:02 schrieb Tim Bunce <tim.bu...@pobox.com>:
> 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
rehs...@gmail.com
