Baby Moose Move Out

Just cleaning up the Moose-Pen today.

I left off from yesterdays post with few more tests to clean up and a new one or two to write up. Might as well get the low hanging fruit first and that is this error;

Can't locate object method "dynamic_conditions" via package "Database::Accessor::Driver::Test" at 43_dynamic_conditions.t line 54.
and the change was a very easy removal of that 'dynamic_' from the test;

    $in_hash->{conditions},     $da->dynamic_conditions(),
--    $dad->dynamic)conditions(), 'dynamic conditions'
++    $dad->conditions(), 'dynamic conditions'
and to carry on with this one I had a look at the other test cases that used 'deep_predicate' and got '47_dynamic_gathers.t' all fixed up in one go as well. The little nasty was this one

Can't locate object method "dynamic_links" via package "Database::Accessor::Driver::Test" at D:\GitHub\database-accessor\t\lib/Test/Database/Accessor/ line 94.
found when I was trying to get '45_dynamic_links.t' to work. A little more involved as this is a change to the 'sub deep_links' found in my test Utils class. Now the testing bug in on this line

    ok(ref( $dad->dynamic_links()->[$index] ) eq 
                "Dad link $index is a Link");
Now that I no longer have ' dynamic_links' on my DAD but just one array of both static and dynamic I have to take that into account by add in in the number of 'links' in the DA to the index I am searching on, Fortunely this is Moose and I can get that with the 'Array Trait' I added in so all I need to do is

           ok(ref( $dad->links()->[$da->link_count()+$index] ) eq 
                "Dad link $index is a Link");
and then make the same sort of change for the rest of the 'deep_links' sub and my '45_dynamic_links.t' then runs perfectly.

Next was a quick clean up on '49_dynamic_sorts.t' where all I had to do was replace '$dad->dynamic_sorts' with '$dad->sorts' and the test case ran successfully.

Finally I can add in a few test to check the new functionality I have added in over the past few days. First I want to check to see if 'gathers', 'filters' and 'sorts' are only being passed in on a 'retrieve' call. I can do this by simply adding on a few tests at the end of some existing test cases.

If I start by adding these to key to the '$in_hash' found int test case '37_gathers.t'

my $in_hash = {
++ delete_requires_condition => 0,
++ update_requires_condition => 0,
and as the last part I add this;

foreach my $type (qw(create update delete)){
   $da->$type( Data::Test->new(), {test=>1} );
   $dad = $da->result->error(); #note to others this is a kludge for testing
   ok($dad->gather_count ==0, “No Gathers on $type”);
   ok($dad->filter_count ==0, “No Filters on $type“);
I will get this

ok 11 - No Gathers on create
ok 12 - No Filters on create
ok 13 - No Gathers on update
ok 14 - No Filters on update
ok 15 - No Gathers on delete
ok 16 - No Filters on delete
of course I need those two keys at the start to allow me to Update and Delete without a condition to avoid a fail like this;

Attempt to DELETE without condition at D:\GitHub\database-accessor\lib/Database/ line 571.
I was thinking I could try and re-factor this by adding it into the Utils and use is again in the '39_sorts.t' test case but decided not to as in that test case there are no 'Gathers' or 'Filters' and I would have to introduce more logic another variable to control which attributes are checked. So I went with the Keep It Simple Stupid principle as a little code duplication in tests is ok if it avoids the possibility of introducing more typos. In the end I '39_sorts.t' is giving me;

ok 9 - No Sorts on create
ok 10 - No Sorts on update
ok 11 - No Sorts on delete
so I am happy with that. Finally I can move onto the 'element' flag tests and I can easily add them to '31_elements.t'. I really only have four to test no_create, no_retrieve, no_update, and only_retrieve as is_identity will only be used on the DAD side of things so not to bore you will all the iterations I went though and the two bugs I found (see if you can spot them in this post) to get to what I wanted I will just show you the end result;

$in_hash->{delete_requires_condition} = 0;
$in_hash->{update_requires_condition} = 0; 
$in_hash->{elements}->[0]->{no_retrieve} = 1;
$in_hash->{elements}->[1]->{no_create}   = 1;
$in_hash->{elements}->[2]->{no_update}   = 1;

$da = Database::Accessor->new($in_hash);
$da->retrieve( Data::Test->new(), $return );
$dad = $da->result->error();
ok($dad->element_count == 2,"only two Elements retrieve");
ok($dad->elements->[0]->name eq 'last_name',"last_name is index 0");
ok($dad->elements->[1]->name eq 'user_id',"user_id is index 1");

$in_hash->{elements}->[0]->{only_retrieve} = 1;

$da->create( Data::Test->new(), {test=>1} );
$dad = $da->result->error();
ok($dad->element_count == 1,"only one Element on create");
ok($dad->elements->[0]->name eq 'user_id',"user_id is index 0");

$da->update( Data::Test->new(), {test=>1} );
$dad = $da->result->error();
ok($dad->element_count == 1,"only one Element on create");
ok($dad->elements->[0]->name eq 'last_name',"last_name is index 0");
re-ran the full test suite and opps got this;

t/60_env_vars.t .. Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/3 subtests
Thank goodness for test driven development as it only too quick look into to see that I forgot the make a little change in my new “Common” role;

       has [
        ] => (
          is          => 'ro',
          isa         => 'Bool',
 ++       default     => 0,
 ++       traits => ['ENV'],
and once that was in and one more quick fix for a tests miscount I am now getting;

All tests successful.
Files=25, Tests=324, 41 wallclock secs ( 0.21 usr  0.05 sys + 37.62 cusr  2.16 csys = 40.04 CPU)
Result: PASS
So back to Driver::DBI at last?


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