Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Easier Mocking?

by water (Deacon)
on Sep 27, 2005 at 10:50 UTC ( #495322=perlquestion: print w/replies, xml ) Need Help??
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 } }
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 --


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

Replies are listed 'Best First'.
Re: Easier Mocking?
by xdg (Monsignor) on Sep 27, 2005 at 11:33 UTC
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.
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, 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:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://495322]
Approved by holli
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (9)
As of 2017-07-25 06:08 GMT
Find Nodes?
    Voting Booth?
    I came, I saw, I ...

    Results (363 votes). Check out past polls.