byterock

Well I would not be a very good CPAN programmer if it did not think of a set of tests before I started any project so let take a look at what I have.

Fortunately for my Data Accessor (still haven't come up with a new name for it) I have inherited a rather large test suite of about 200+ tests. Unfortunately for my Data Accessor I have inherited a rather large test suite.

Lets have a look at one

 
#!/usr/bin/perl
use Test::More;
plan tests => 5;

  require_ok( 'CS::DA::Address' );

  my $test = CS::DA::Address->new();

  $test->add_dynamic_condition({field   => $test->field_named("id"),

                        operator=>'=',

                        param   =>1});

   ok($test->_insert({street=>'123 Sesimie',

                                city=>'New Tork'}) 

        eq "INSERT INTO address (city, street ) VALUES ( ? ,  ? )"

        ,"Insert Address");

   ok($test->_select() 

      eq  "SELECT address.id, address.street, address.city, address.postal_code, 

             address.region_id, address.country_id, address.time_zone_id FROM address WHERE address.id= ?"

       ,"Select Address");  

   ok($test->_update() 

      eq "UPDATE address SET street =  ? , city =  ? , postal_code =  ? , region_id =  ? , country_id =  ? , time_zone_id =  ?  WHERE address.id= ?"

      ,"Update Address");   

    ok($test->_delete() 

      eq "DELETE address WHERE address.id= ?"

     ,"Delete Address");

Well at least I get this

 
1..5
ok 1 - require CS::DA::Address;
ok 2 - Insert Address
ok 3 - Select Address
ok 4 - Update Address
ok 5 - Delete Address

Hmm must have been paid by the line or test when I was writing these up.

Quickly looking through what I have handy I can see I just have unit tests for a batch of Data Accessor instances and there is very little coverage of Data Accessor.

I am ignoring the higher level functions found in DA.pm like 'create' and 'update' and diving into private functions found in the SQL.pm to check what SQL commands are generated. I only imply that 'add_dynamic_conditions' is working by the follow on checks of the generated SQL code as they are looking for '?' in the static SQL. One glaring ommisson is I never check to see if the param values are somewhere in the Class and if they line up correctly with the placement of the '?' in the generated SQL.

What I am seeing here is a good deal of trust in the Data Accessor code. This would be the same case when using DBI in a project. Nobody would re-test DBI to check to see if it is all working (apart form connecting) when it is used in the back end of a website, unless of course if you where being paid by the test.

So If I want to send this out to CPAN someday I will need to really look at what tests I am going to do to give users that same level of confidence that comes with using a high Kwality CPAN module.

Now the basic idea of Data Accessor is a common CRUD interface for many Data bases or, perhaps other data sources. So the above test will not be much use for my core module, as one should never assume that all users will want to use the SQL.pm part. Well at least I when I go to write up the test suite for SQL.pm I will have some base test to start with.

So DA needs a stand alone test suit. I will have to take a lesson from DBI (always check out other test suits) and come up with a suite that will test the base functionality but no requirement that and particular data source driver be loaded. Hmm I like the sound of that DSD or maybe LSD (Loaded Data Source)

I guess I will have to take a close look at the the API DA.pm is going to expose and work from there. Maybe a mock DSD will be needed to test?.

This little exercise has also shown me that I will need to package up my code as a core package DA (or whatever) and its test suite and my Drivers DSDs or LSDs each with their own test suite in separate packages.

Oh well onto bigger things.