On Tue, Jan 10, 2012 at 12:41, Nicholas Clark <n...@ccl4.org> wrote: > On Tue, Jan 10, 2012 at 12:19:19PM +0000, Peter Sergeant wrote: >> On Tue, Jan 10, 2012 at 9:56 AM, Ian Knopke <ian.kno...@gmail.com> wrote: >> >> > I need to test some DBIx::Class code where the database may not be >> > available. I can set up something to generate a small, temporary >> > SQlite db, but I was wondering what approaches others are currently >> > using for this. DBD::Mock seems ok but not especially well suited for >> > use with DBIx. What does the rest of the community currently do? >> > >> >> I've tried a few approaches with this. Where I've used a different DB >> backend, I've been bitten by differences in the DB from Unicode handling to >> different feature sets. Where possible, a blank(ish) testing database >> running the same DB software as the target is infinitely preferable to >> faking it with a different system. > > Yes, at ex-employer, it came to pass that trying to test a MySQL database > using fixtures in SQLite produced a steady stream of work trying to cope > with differences between the two, which only emerged as one tried to write > tests for more parts of the system.
Thirded, and not even the project that Pete & I have worked on together :) All this portability hairiness notwithstanding, there's an argument to be made that if your prod system is using one particular DB then the test system should really be running that as well. If the tests pass on a mock or similar in-RAM doodad or whatever that doesn't leave me at least as confident about a deploy as if it'd successfully run on the same platform as live. Paul