A solution to that particular problem is to restructure a class to make use a "database interface" class that can be passed in either at object creating time or to a method that populates an instance of the object.
I like this idea a lot, and I do use a database wrapper for most code I write now. At some point I will probably write another wrapper to do what you mention.
I do have another suggestion, which is the approach I've been using lately. I'm trying to follow the MVC concept where it makes sense. Hence I have broken down the various data types into Model modules. They have a dependency on each other like: Change needs Event needs Provider. So I started at the top (Provider) and wrote the module & tests. It works great. Then I wrote the Event module. In the test for it, I use the Provider object I just finished to create dummy entries in the database. Then I run my tests on this known data and verify all is well. Then I delete everything at the end of the test. All is well and I've just used up a few auto_increment id's - no big deal.
The disadvantage to this approach is that while in development you'll most likely get quite a few invalid entries left in the database. In my case it's no big deal to clean them up by hand. You should keep this fact in mind when using this approach.