|P is for Practical|
Easier Mocking?by water (Deacon)
|on Sep 27, 2005 at 10:50 UTC||Need Help??|
water has asked for the
wisdom of the Perl Monks concerning the following question:
Problem BackgroundI 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:
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 AskedThis 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 --