Testing databases with DBIx::Class

Leo Lapworth leo at cuckoo.org
Tue Jan 10 13:48:25 GMT 2012

On 10 January 2012 12:53, Paul Makepeace <paulm at paulm.com> wrote:
> On Tue, Jan 10, 2012 at 12:41, Nicholas Clark <nick at 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.knopke at 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:

    use $WORK::Core;

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.


More information about the london.pm mailing list