Moose vs the API Change Gang
Its not the end of a story but the beginning of one here in the Moose-Pen today.
When we last saw our hero he was deep into the lair of the dreaded API change gang, Fending off invalidated tests cases left right and center until there was only one left!!
The much to be feared! Test case 't/58_parenthes.t'.
The first error was;
not ok 11 - OR added to last gather condition predicate
Now that my API has changed the following test;
$da = Database::Accessor->new($in_hash3);
ok($da->default_condition('OR'),'Change Defalut condition to OR');
$da->retrieve( Data::Test->new());
ok(
$da->result->error->gather->conditions->[1]->predicates->condition() eq
'OR',
'OR added to last gather condition predicate'
);
is not really valid anymore as I am considering all the 'Static' attributes to be imitable which sort of fixes yet another back door to my Database::Accessor as all a use use to have to do was this;
$da->default_condition('IS NOT');
then the next time the $da is run anywhere a condition was not explicit set it would come up as a 'IS NOT' which could yield some odd results. The 'default_condition' is still useful for dynamic conditions but I will have to adjust my test a little;
$da = Database::Accessor->new($in_hash3);
$condition->{close_parentheses} =0;
ok($da->default_condition('OR'),'Change Defalut condition to OR');
$da->add_condition($condition);
$da->add_condition($condition);
$da->retrieve( Data::Test->new());
ok(
$da->result->error->gather->conditions->[1]->predicates->condition() eq
'AND',
'AND still last gather condition predicate'
);
ok(
$da->result->error->conditions->[1]->predicates->condition() eq
'OR',
'OR added to last condition predicate'
);
I keep the change to 'OR' then I add in two dynamic conditions and finally test to make sure my static predicate is still and 'AND' and the dynamic_conditions are set to an 'OR'. Lets see what I get;
...
ok 10 - Change Default condition to OR
ok 11 - AND still last gather condition predicate
ok 12 - OR added to last condition predicate
…
The other two fails on the page where the same sort of change so I will not bore you with those. The next fail was on;
not ok 18 - Caught left open parentheses missing
which is this test;
delete( $in_hash->{elements}->[0]->{left}->{open_parentheses} );
like(
exception {$da = Database::Accessor->new($in_hash)},
qr /Unbalanced parentheses in your static attributes/,
"Caught left open parentheses missing"
);
Which should of fired off an error but didn't. Into the code I go. The only change that was required was this line in the '_elements_check' sub;
$self->_reset_conditions()
++ if ($type ne 'static');
Which should cause any 'static' conditions that I add to fail if they come in on an array and are unbalanced.
With the last of the 'API change gang' behind bars and singing like canaries. Our intrepid hero has enough dope to go after 'DAD' the big boss and his 'DBI' test posse.
Will 'DAD' and his test posse be too much for our Hero to handle?
Will bid boss 'DAD' use his secret weapon, the 'practical minions' to foil our Hero?
Will our Hero prevail?
Tune in tomorrow!
Same perl time!
Same perl blog!
For chapter '334' of our story
Leave a comment