Testing databases with DBIx::Class
Hi, 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? Ian Knopke BBC (Recommendation Systems)
Re: Testing databases with DBIx::Class
On 10 January 2012 09:56, Ian Knopke wrote: > Hi, > > 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'd have a look at DBIx::Class:Fixtures, I've also manually created fixture data in scripts in the past (and present) too. A. -- Aaron J Trevena, BSc Hons http://www.aarontrevena.co.uk LAMP System Integration, Development and Consulting
Re: Testing databases with DBIx::Class
On 10 January 2012 10:12, Aaron Trevena wrote: > On 10 January 2012 09:56, Ian Knopke wrote: >> Hi, >> >> 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'd have a look at DBIx::Class:Fixtures, I've also manually created > fixture data in scripts in the past (and present) too. > I have a semi automated DBIx::Class::Factory class I wrote specifically for the purposes of creating test data (you request the object you want and it automatically resolves the dependant objects and creates them for you with semi random data). The main reason for auto creation of the parent objects is often the size of your "create test data" function/fixtures/sql file exceeds the size of the test. You'd still need to be running SQlite or a database of some sort in the background (and it assumes relationships are set up correctly such that it can resolve parent objects). I am intending to tidy it up and put it on CPAN at some point but have been rather busy unfortunately. If it scratches your itch I can spend an hour or two tidying it up slightly and pass it along. It works something like the following: my $account = DBIx::Class::FactoryNew::create_Account( name => 'Test Account', active => 1, ); my $user = DBIx::Class::FactoryNew::create_User( account => $account, name => 'Test user, active => 1, ); Any field or relationship which is not passed in will be filled with random data (such that you're not relying on anything you shouldn't be). If you simply required a User object you would: my $user = DBIx::Class:FactoryNew::create_User( name => 'Test user, active => 1, ); After which the parent account object would be automatically created for you and filled with random data. Thanks Gareth
Re: Testing databases with DBIx::Class
Ian Knopke writes: > Hi, > > 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? At work we use Test::DBIx::Class, which can use an SQLite database or a scratch MySQL or PostgreSQL instance (no root or CREATE DATABASE privilege needed). -- ilmari "A disappointingly low fraction of the human race is, at any given time, on fire." - Stig Sandbeck Mathisen
Re: Testing databases with DBIx::Class
On Tue, Jan 10, 2012 at 09:56:04AM +, Ian Knopke 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? The Dynamite team have some code for mocking their database. Talk to Udo. -- David Cantrell | Nth greatest programmer in the world I remember when computers were frustrating because they did exactly what you told them to. That seems kinda quaint now. -- JD Baldwin, in the Monastery
Re: Testing databases with DBIx::Class
On Tue, Jan 10, 2012 at 9:56 AM, Ian Knopke 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. -P
Re: Testing databases with DBIx::Class
On Tue, Jan 10, 2012 at 12:19:19PM +, Peter Sergeant wrote: > On Tue, Jan 10, 2012 at 9:56 AM, Ian Knopke 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. (eg differences in SQL, what functions are named, emulating functions, that in SQLite everything is a string) Whereas building a system using MySQL's fast flat file loader paid off in the medium term, as it eliminated needing to code around differences, because the test database system was pretty much identical to the real thing. Nicholas Clark
Re: Testing databases with DBIx::Class
On Tue, Jan 10, 2012 at 12:41, Nicholas Clark wrote: > On Tue, Jan 10, 2012 at 12:19:19PM +, Peter Sergeant wrote: >> On Tue, Jan 10, 2012 at 9:56 AM, Ian Knopke 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
Re: Testing databases with DBIx::Class
If it's MySQL, it can be run embedded, which is what we have been doing at work. -- Best regards, Egor Shipovalov. On Tue, Jan 10, 2012 at 9:56 AM, Ian Knopke wrote: > Hi, > > 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? > > > Ian Knopke > BBC (Recommendation Systems)
Re: Testing databases with DBIx::Class
On 10 January 2012 12:53, Paul Makepeace wrote:
> On Tue, Jan 10, 2012 at 12:41, Nicholas Clark wrote:
>> On Tue, Jan 10, 2012 at 12:19:19PM +, Peter Sergeant wrote:
>>> On Tue, Jan 10, 2012 at 9:56 AM, Ian Knopke 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_
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
Re: Testing databases with DBIx::Class
On Tue, 10 Jan 2012, Leo Lapworth wrote: A full dump of live is imported to dev every sunday, when we're running on a dev server Except that if this includes personal data, and your customers didn't sign up to agree to be test subjects, then it's a breach of data protection laws to reuse data gathered for another purpose. A lot of companies do this (either a full copy or some subset to make processing lighter) but few have the right words in their statement. the hatter
Re: Testing databases with DBIx::Class
On 10 January 2012 16:01, the hatter wrote: > On Tue, 10 Jan 2012, Leo Lapworth wrote: >> A full dump of live is imported to dev every sunday, when we're running on >> a dev server > > Except that if this includes personal data, and your customers didn't sign > up to agree to be test subjects, then it's a breach of data protection laws > to reuse data gathered for another purpose. A lot of companies do this > (either a full copy or some subset to make processing lighter) but few have > the right words in their statement. Ahh, good point, thankfully none of our systems have personal data, that's all the CRM teams problem :) Leo
Re: Testing databases with DBIx::Class
On 10 January 2012 16:01, the hatter wrote: > On Tue, 10 Jan 2012, Leo Lapworth wrote: > >> A full dump of live is imported to dev every sunday, when we're running on >> a dev server > > > Except that if this includes personal data, and your customers didn't sign > up to agree to be test subjects, then it's a breach of data protection laws > to reuse data gathered for another purpose. A lot of companies do this > (either a full copy or some subset to make processing lighter) but few have > the right words in their statement. > I have worked at a company where the dump from live was put through an 'anonymiser' script to remove sensitive data or replace it with appropriate random text/numbers, but this of course requires more care and work. > > the hatter
Re: Testing databases with DBIx::Class
On Tue, Jan 10, 2012 at 04:01:23PM +, the hatter wrote: > On Tue, 10 Jan 2012, Leo Lapworth wrote: > >A full dump of live is imported to dev every sunday, when we're running on > >a dev server > Except that if this includes personal data, and your customers didn't sign > up to agree to be test subjects, then it's a breach of data protection > laws to reuse data gathered for another purpose. A lot of companies do > this (either a full copy or some subset to make processing lighter) but > few have the right words in their statement. And even if you *do* have the right words, it's a Bad Idea. You don't want your tests to accidentally email your customers, for example! -- David Cantrell | Official London Perl Mongers Bad Influence Guns aren't the problem. People who deserve to die are the problem.
Re: Testing databases with DBIx::Class
Running a one-way data-munger on the data would be a fair way to anonymize the client sensitive content. This has the benefit of using near-perfect data for testing. And while using "fixtures" and SQLlite is a great drop-in fudge, it's still a fudge because it's not the same database system, the database functionality is different, and the perl DBIx code is not the same either. It's similar, but it's not the same. You end up testing apples and pears, similar perhaps, but definitely not the same. -- Ciao Richard Foley http://www.rfi.net/books.html On Tue, Jan 10, 2012 at 04:01:23PM +, the hatter wrote: > On Tue, 10 Jan 2012, Leo Lapworth wrote: > > >A full dump of live is imported to dev every sunday, when we're running on > >a dev server > > Except that if this includes personal data, and your customers > didn't sign up to agree to be test subjects, then it's a breach of > data protection laws to reuse data gathered for another purpose. A > lot of companies do this (either a full copy or some subset to make > processing lighter) but few have the right words in their statement. > > > the hatter
Re: Testing databases with DBIx::Class
On 10 January 2012 17:07, David Cantrell wrote: > On Tue, Jan 10, 2012 at 04:01:23PM +, the hatter wrote: >> On Tue, 10 Jan 2012, Leo Lapworth wrote: >> >A full dump of live is imported to dev every sunday, when we're running on >> >a dev server >> Except that if this includes personal data, and your customers didn't sign >> up to agree to be test subjects, then it's a breach of data protection >> laws to reuse data gathered for another purpose. A lot of companies do >> this (either a full copy or some subset to make processing lighter) but >> few have the right words in their statement. > > And even if you *do* have the right words, it's a Bad Idea. You don't > want your tests to accidentally email your customers, for example or auto-tweet from a random user, that happens to be an investor in the company, that they had just watched a pretty lame film and suggest it to their friends on twitter.. yes really, this actually happened :) A. -- Aaron J Trevena, BSc Hons http://www.aarontrevena.co.uk LAMP System Integration, Development and Consulting
