Just A Cute Moose

Well today in the Moose-pen I am still going to have a look at my 33_conditions.t test case. In my last post I got all the little bits working right up to the point when I want the DAD to return or at least crate this string


After sleeping on it and then playing a bit I came to the very wise conclusion to not to test my Accessor in this way. If I take this path then I am opening myself up to going down all sorts of test rabbit holes where there is nothing wrong with my Accessor but a problem in my Tests DAD. So what to do?

Well lets have a look at what I have to test:

  • coercion from a hash to a type works correctly
  • class attribute values passed into the DAD are correct
Well for the coercion all I need to do is what I am presently doing, pass in a Hash-ref and see if it errors. I can then iterate over the same hash to check that my Data was passed in correctly, simple enough. So that is one done.

To accomplish the second goal I will need the DAD to test. Now as I envision the working of
Accessor, you would not access the DAD directly. So to remedy this all I need to do is return the DAD when I do one of the CRUD calls to it.

So in 'Database::Accessor::DAD::Test' all I need to do is

sub Execute {
my $self = shift;
return $self;

Then test on what is coming back. So now in my test I can do this

my $dad = $user->retrieve($data,$return_str);
ok(ref($dad) eq "Database::Accessor::DAD::Test",'Got the Test DAD');

Now I had previously made the choice to split my tests up into small easily tested blocks so all I need to test is what is going into the Accessor conditions matches what comes out is correct and test that the Conditions Attribute in the DAD matches what is in Accessor.

So I do have what I want to end up with by spliting this out into its own hash;

my $in_hash = {
view => {name => 'People'},
elements => [{ name => 'first_name',
view=>'People' },
{ name => 'last_name',
view => 'People' },
{ name => 'user_id',
view =>'People' } ],
conditions=>[{ left =>{ name =>'user_id',
view =>'People'},
operator => '=',
right =>{ param=>'test'}},
{ condition=>'AND',
my $da = Database::Accessor->new($in_hash);

So all I have to do is iterate over that hash and test what is in my conditions and Conditions hash. Well I am not going to go down that rabbit hole. I would have to write a lines and lines of code the check level of this simple data structure. I did a few lines of code for it and soon I had 15 lines of code and I only tested the elements part of the hash.

Perl does have much easier ways to test such data structures namely Test::Deep.

So to test the above hash against my created classes all I need to do is;

my $da_conditions = $da->conditions();
my $dad_conditions = $dad->Conditions();
my $in_conditions = $in_hash->{conditions};
foreach my $index (0..scalar(@{$in_conditions}-1)) {
my $in = $in_conditions->[$index];
cmp_deeply( $da_conditions->[$index], methods(%{$in})," DA condition attributes correct ");
cmp_deeply( $dad_conditions->[$index], methods(%{$in})," DAD Condition attributes correct " );

in the first part I just put the attributes into vars so my code will be a little easier to read. Next I iterate over the count of my 'in conditions' and in there I do a cmp_deeply the in values with what 'methods' are in expected in my in hash.

So I run that above and I get a number of these fails

# Compared $data->operator
# got : Does not exist
# expect : '='

ok 2 - Got the Test DAD
not ok 3 - DA condition attributes correct

opps! Looking back at Accessor I see that I had commented out the 'operator' attribute on the Database::Accessor::Condition class. So I took the comments out and reran my test and I get

# Compared $data->left # got : Does not exist …

So I have to make another stab at it.


Leave a comment

About byterock

user-pic Long time Perl guy, a few CPAN mods allot of work on DBD::Oracle and a few YAPC presentations