byterock

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;

Test::Database::Accessor::Utils::deep_predicate(

    $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/Utils.pm 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 

              "Database::Accessor::Link",

                "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 

                "Database::Accessor::Link",

                "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/Accessor.pm 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");

delete($in_hash->{elements}->[0]->{no_retrieve});

$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 [

        qw(da_compose_only

           da_no_effect

           da_warning

          )

        ] => (

          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?