I recently posted a message to the dbi-dev mailing list about a mock DBD implementation. This is different than the dynamically mocked database handle chomatic discussed in his real-world example of Test::MockObject. There he replaced a package variable with a dynamic mock that would do what he wanted.
I need something different - a DBD implementation that DBI will load (when calling connect()) and act just like a normal driver, like those for Postgres or MySQL. This makes it possible to use your properly decoupled configuration to specify your mock implementation. For example, the initial declaration might look like:
<persister name="TestPersister"
class="Workflow::Persister::DBI"
dsn="DBI:Pg:dbname=ticket"
user="test"
password="test"/>
So in your tests you have the option of using an in-memory or file-based database (like SQLite) and actually execute statements against it. But this creates an additional dependency which I'd rather not do. Another option is to replace the configuration with something like:
<persister name="TestPersister"
class="Workflow::Persister::DBI"
dsn="DBI:Mock:"/>
And all your plumbing will Just Work. Then you can ask the plumbing if what you expected to happen happened (ask it about the SQL statements and bound parameters, for instance) and make that the foundation of some excellent tests. That's the goal of mock implementations like these. And AFAIK this is an area where Perl lags behind Java, which has a number of implementations in the Mock Objects framework to represent servlets, EJB containers, JDBC connections, resultsets, statements and the like. Hopefully we can pick up some slack and make it easier to test this stuff.