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;

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?

IMG_5552a.jpg

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