Easier Mocking?

water has asked for the wisdom of the Perl Monks concerning the following question:

Problem Background

I have a piece of an application that stores information about samples in a database.

Samples have dimensions like size, color, temp, volume, melting point; each dimension has a fixed number of attributes (for example, size --> small, medium, large; temp --> low, high, etc).

I have code like this:

# psuedo-code
foreach $sample
  foreach $dim
     determine attribute for sample for dim
     store (sample_id, dim_id, att_id) in database
  }
}
[download]

Now, the dimensions and samples are stored by dim_id and att_id in the sample_info table, which are foreign keys into the dimension and attribute tables (these contain full information on each dim and att).

Also, sometimes the dim and att need to be created on the fly -- long story why, but true. In this case, given a sample should fall into dimension "woozle" with attribute "foozle", new rows must be cut in dimension and attribute before we can store (sample_id, dim_id, att_id) in database.

Final detail: all db access is thru class::dbi.

Problem Asked

This part of the app is a monster to test. It is soooo tightly coupled with the database it hurts.

I'm looking for advice.

I don't want to test using bogus samples going into the database; I don't want to delete them and don't want them there.

This leads me to heavy us of Test::Class, Test::MockObject, and Sub::Override.

Heavy heavy use.

I've had trouble using Override on CDBI autocreated methods like 'search' -- thus, I've needed to push that functionality into methods to be able to override (eg mock) those.

Test::Class saves me a great deal of time, because the painful set-up stuff to do testing (200+ LOC, at this point, and not simple lines) can be recycled.

But this is still a pain.

Any advice, wise monks, on testing a CDBI app using mocking, besides placing just about every DB call (search / update / create) in its own micro-method, so it can tested and then overriden when used to test a parent method?

Too much mock code --

water

2005-09-29 Retitled by g0n, as per Monastery guidelines
Original title: 'Eaiser Mocking?'

Comment on Easier Mocking? Select or Download Code

Replies are listed 'Best First'.
Re: Easier Mocking? by xdg (Monsignor) on Sep 27, 2005 at 11:33 UTC
In Re: Testing procedure: how to mock?, stvn suggests DBD::Mock, among other things. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply]
Re: Easier Mocking? by Anonymous Monk on Sep 27, 2005 at 11:34 UTC
You don't have a test database you can use? In a previous job, I often needed to develop stuff against an (existing) database. I had my own Oracle server running on my desktop (just like most developers), and had a copy of a database loaded with typical data. I could muck around in the database all I wanted - rolling back was to a default state was trival - just load back the database copy.	[reply]
Re: Easier Mocking? by dragonchild (Archbishop) on Sep 27, 2005 at 13:21 UTC
This is exactly what DBD::Mock was designed for ... kinda. Chris Winters, then stvn and I, planned DBD::Mock to be for people who use DBI directly. We have only just started playing with Class::DBI ourselves. It may be useful to come up with a way of mocking CDBI itself, because that's the interface you want to test, not DBI's interface. I suggest emailing the CDBI mailing list. Some quick googling reveals http://www.spanner.org/lists/cdbi/2005/03/05/e66a0853.html, implying that DBD::Mock and CDBI don't work together out of the box, at least in that scenario. Maybe Class::DBI::Mock needs to be written. I don't think it's a simple thing, though, given the amount of work that goes on behind the scenes in CDBI and how tightly some of it's coupled to other things. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^2: Easier Mocking? by vampirechicken9 (Initiate) on Sep 27, 2005 at 15:11 UTC
Maybe Class::DBI::Mock needs to be written. I don't think it's a simple thing, though, given the amount of work that goes on behind the scenes in CDBI and how tightly some of it's coupled to other things. I think that you could get away with using Class::Accessor to create the CDBI::Mock objects, and then loading them with canned data before returning them to the caller. But I must agree, that the poster would be well served in the long run by setting up a dev database.	[reply]


Don't ask to ask, just ask
	PerlMonks