Skip to content
Kirill Müller edited this page Sep 2, 2015 · 1 revision

This section describes an alternative definition for the package's interface using inversion of control.

Functions

The entire test suite can be run with one single function call. Example file (in tests/testthat):

DBItest::test_all(Driver(), connect_args = list(...))

Testing is tightly coupled with testthat -- the test_all function will call testthat::context() and testthat::test_that() as appropriate. Support for RUnit can be added later if necessary.

Running only parts of the test suite is supported, via helper functions (DBItest::test_xxx(drv, connect_args)) and a function that takes an argument (DBItest::test_some(drv, what, connect_args)). In test_some, what can be a vector. This makes it easy to run the tests from a console when working on a backend.

If connect_args is NULL, the connection parameters are queried from a global option.

Opt-out

The DBI backends state which parts of DBI they support to what extent (and therefore can be tested). With this approach, the test logic is not coded explicitly into each backend, but queried by DBItest as necessary. OLE DB and ODBC have similar facilities. For querying the information, a new function should be part of the DBI interface: dbGetFeature, signature: DBIDriver, character and, if necessary, DBIConnection, character. This function accepts a property name and returns a value, which can theoretically depend on the connection. Unknown properties should return a default value (NULL or NA) to allow further extensions. The list of valid properties, their type, and the default value, is part of the DBI specification. Obvious candidates:

  • Transaction support (nested?)
  • Supported data types
  • SQL names for data types
  • Listing connections (see RSQLite)
  • UTF-8 support
  • Prepared statements (dbBind)

Further properties are added as necessary.

Testing packages written from scratch using a test-first approach will be possible. Special "work in progress" properties in the DBI backend indicate which parts of DBI are implemented (or not); the tests will skip those parts that are marked as broken.

Clone this wiki locally