On 10 January 2012 12:53, Paul Makepeace <pa...@paulm.com> wrote: > 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?
We rely on having a database, actually several... ALL our code (including DBIx:: Schemas) uses one module to work out how to connect to a database, this code can tell if we are on a live server, a development machine or in testing mode. We then run 3 databases (all one beefy server with replication to a backup) 3306 = live 3307 = dev 3309 = testing A full dump of live is imported to dev every sunday, when we're running on a dev server (designers have their own VM's, and developers share one VM) the code can ONLY connect to dev or testing (requires a method to be called first).... For testing... All tests have: BEGIN { use $WORK::Core; $WORK::Core->test(1); } Each in each package we have a 00_setup.t script, this lists which tables and what data is needed for the package tests, it creates USERNAME_<TABLE> in the testing database and populates the data. Then when the rest of the test scripts run they are talking to these tables. This works really well for how we're setup, obviously during development we only run 00_setup.t once, then run the individual test scripts. Not quite what you were after, but this is our approach. Leo