Baby Moose almost ready

Test case clean up day today in the Moose-Pen

All those changes I introduced in my last post did quite a job in mucking up my test suite as the latest run results show;

Files=27, Tests=328, 39 wallclock secs ( 0.24 usr 0.06 sys + 36.90 cusr 1.92 csys = 39.12 CPU)
Result: FAIL
Failed 9/27 test programs. 37/328 subtests failed.

The first thing I noticed was not a fail in a test but this warning;

Use of uninitialized value in string eq at …/lib/Database/ line 37.

coming up all over the place, I should of caught earlier but that is why we run tests. A little change in my 'around BUILDARGS' sub;

$element->{view} = $view_name
              if (!exists($element->{expression}) 
                 and !exists($element->{function})
                 and !exists($element->{value})
--                 and $element->{view} eq undef );
++                 or ( !exists($element->{view})
++                 or $element->{view} eq undef ) );
A common mistakette where the key may not exists and you test as if it does.

The next major problem I was seeing is this fail

# Extra: 'is_identity', 'no_create', 'no_retrieve', 'no_update', 'only_retrieve'

That is caused by my 'Element' class now having a bunch of new attributes that I added in that are not normally found in the hash that is passed into on a new;

Right now I am trying to fix up 33_conditions.t and the $in_hash the elements array is

my $in_hash = {
view => { name => 'People' },
elements => [
name => 'first_name',
view => 'People'
name => 'last_name',
view => 'People'
name => 'user_id',
view => 'People'

and I could fix this by adding in all those keys to my hash but that would be a little ham-fisted for my tastes. The real problem is that I gave each of these flags have a default value that is set at instantiation and I think this simple fix in the 'Elements' class;

has [
] => (
is => 'rw',
isa => 'Bool',
-- default => 0,

and after I fix up a few test counts I get

All tests successful.
Files=26, Tests=328, 39 wallclock secs ( 0.19 usr 0.06 sys + 36.51 cusr 1.85 csys = 38.61 CPU)
Result: PASS

Now I have to test the 'Element' class flags and I still need test to see to see if some of the attributes passed into the DAD are empty, for example no sort on a 'create' action.

Now I started working on the 50_create.t test case and I wanted to check that the 'gathers' array is empty and I add in this quick test

my $driver = $da->result()->error(); #klugde for testing
ok(scalar(@{$driver->gathers()}) == 0,'No gathers');

and I get the correct value on test

ok 8 - No gathers

But that got me thinking why don't I have a 'gather_count' on that element so I could just do this

my $driver = $da->result()->error(); #klugde for testing
ok($driver->gathers()->gather_count) == 0,'No gathers');

and I checked all my attributes and I never did add in the ”traits => ['Array'],” on most of my array attributes and in the 'Database::Accessor::Roles::Driver' I did not add any. I was just about to fix that when I realized that I had no reason to pass in all those 'dynamic_' attributes to the DAD I should just pass both the dynamic and static classes on one attribute just to make the DAD interface even more simple.

Well one thing lead to another and soon I say I think I could take all the common attributes between a Database::Accessor class and a Database::Accessor::Driver class so I think I have a topic for tomorrow's post.

Oh well that iterative programming for you.


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