So one of the biggest things I've run into in drupal-land is that it's virtually impossible to test database interactivity without actually touching the data on a live site. I started kicking around some ideas last night and came up with a half-way solution that may solve at least the first round of headaches with this.

The Criteria

Ideally, I wanted a solution that:

1. does not rely on requests to the database to test a certain component.
2. preserves existing data
3. allows me to test certain conditions based on the way the data should be returned.

In TDD circles this is defined as "testing in isolation."

The components

database.chaindb.inc

This is essentially a datasource that allows one to chain multiple database elements together.. Ideally this is a case of "try this db engine first.. barring that, run the query against this next one."

database.testdb.inc

This is a datasource that returns a result based on a globally set hashtable. In order to be compatible with drupal's existing db_query, it mocks up the db's resultset resource as a stdclass and returns that. In this way, it can be passed around and not break anything that depends on it.

testdrupal.module

This is a custom module that needs to be written that creates and invokes _testdrupal and _testdrupal_init hooks on all modules. In this way we can run multiple tests and in the order that drupal would normally invoke modules. It also makes it easy to determine which modules do not have tests.

The Process

The following should (ideally) remain true:

• Each module defines its own tests
• Each module should not depend on functionality available in other modules while in test mode. (since it's not possible to override modules, this may be limited to defining return data using testdb)
• Each module should not invoke tests for other modules

Taking that a step further:

• Each module should provide a set of apis for creating mock objects.