byterock

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/Accessor.pm 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 Accessor.pm 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 [

            qw(no_create

              no_retrieve

              no_update

              is_identity

              only_retrieve

              )

          ] => (

            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 Accessor.pm 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.