A few weeks ago I posted a message about a mock DBD and got the response from Tim that DBD::NullP (included in the DBI dist) would be a good place to start. I built on that (but far too much for a patch, sorry Tim) and created DBD::Mock, which does everything I need so far.
It contains everything in a single .pm file to make it easy to ship with your distribution for testing. I plan to make it available on CPAN as well. The docs so far are below. Comments welcome, even if they're of the "dumbest thing I've ever seen" variety :-)
Chris
-------------------- NAME DBD::Mock - Mock database driver for testing
this is very cool. seems to relate strongly to :
"Conformance test script for drivers"
On Sat 17 Jan 2004 15:16, Tim Bunce <[EMAIL PROTECTED]> wrote:
On Fri, Jan 16, 2004 at 07:48:15PM -0500, Thomas A. Lowery wrote:
> > Any volunteers to work on this?
> > I will.
This sounds like it could plug into the trace mechanism, either increasing its
How does it work?
"DBD::Mock" comprises a set of classes used by DBI to implement a
database driver. But instead of connecting to a datasource and
manipulating data found there it tracks all the calls made to the
database handle and any created statement handles. You can then inspect
them to ensure what you wanted to happen actually happened. For
instance, say you have a configuration file with your database
connection information:
leverage, simplifying its implementation, or both. One could write session
tapes during development, while talking to real database pieces, then
reuse them to drive the Mock object.
Another application would be to use a session tape as a log-filter, ie as a set of matching regexes which could subtract out lines of a dbi-log.
Over time, developers could enhance the tape-derived filter-spec, and the dbi-log would get progressively smaller. At some point it would have only the anomalous stuff. They could then be used to validate/assert that chunks of activity were happening as expected, and perhaps kick DBI into trace(9)
these log-subtractors would have to apply sequentially, and to nest,etc so they can match against sequences/loops that would be present in logs.
And having just crept up to a line, let me cross it. Can new DBI2 have 2 logging levels under transactions ? Anything that commits (success) logs at 1 or 2, things that rollback are logged at 5 or 6. This should help unravel anomalous behavior by automatically putting your fovea on it.
This also seems to relate (obliquely) to the way the new set_err() accumulates errors .
now to go read those articles :-D
