My subclasses are autogenerated from a SQLFairy scheme objects (sometime soon it might make it the CPAN), so I have two tests per class:

• schema test
• functionality test

The schema tests make sure that important fields are there, and relationships work, and exist (->meta_info), proper subclassing is done, and so forth. Since all of this is auto generated, I write these before I write the schema, and then go through the schema slowly passing the tests.

The functionality tests take the objects, and create them throught the CDBI interface, and work with them. These tests are not concerned about how the cdbi objects even persist. They would work if a compatible interface was based on Storable, for example. They test the functionality as defined by the subclass.

Since I have funky stuff going on (Class::Delegation AUTOLOADing accessors to a Storable'd has in a BLOB, for example), these tests are pretty comprehensive.

What i'm trying to point out is that this layer, the database persistence, has two concerns - correct definition of the persistence semantics, and correct functionality of the persisting objects (perhaps including the fact that they properly persist). Neither of these concerns have to do with the database itself. That's for Class::DBI to test, and indeed it does. If you feel you can help it test more comprehensively, then you should submit these tests to Class::DBI.