byterock

So in today's Moose pen I am going to stick to the testing tree and have a look at my brand new 20_load_dad.t file in my brand new database-accessor repository

Now in past test cases like this, I did a little creative coding and made up a fake test class for SQL and Mongo drivers that where used when I called this

my $fake_dbh = DBI::db->new();

ok(

    $address->retrieve( $fake_dbh, $result ) eq

      'SELECT  street, city, country FROM person  AS me',

    'SQL correct'

);

Now there is no problem with the use of the fake DBI::db in a test case, the problem that I will encounter is the fact I have to test Database::Accessor as an independent bundle. So that means I have to assume that there will be no DAD present, as we don't want to get into a tail wagging dog situation now do we?

So I have a choice of bundling a DAD with Accessor but which one to choose? Credits to Navy beans any one I choose will not be the one somebody will want to use and I will get all sorts of complaints of may package installing unwanted software.

So what to do? Like many others I will just make a custome test class to use. In this case DAD::Test, and include it in my test suite off the main lib branch so it never gets installed in a Perl path.

Now to create this new DAD I first create a 'lib' dir under my 't' dir, add in the 'Database::Accessor::DAD' name-space and then a Test.pm file to use as my DAD. For that file I just copied over and re-named my last SQL.pm and modified it a bit taking out all the SQL stuff and then for my 'DB_Class' sub I return 'Data:Test'.

As I was moving things about I figured I might as well have the fake data source as a separate file as I would be able to reuse it in other test cases. So I added that under the 't/lib' dir as the 'Data' name-space.

Now, a side note here, when creating a dummy test class like this, it is always a good ideat check to see that you are not conflicting with an existing name-space. In this case I do not, but if I had named it Test::Data I would of opened myself up to whole world of misleading errors if this package happens to be installed on the working path.

So in my 20_load_data.t case I ended up with

#!perl 

use Test::More 0.82;

use lib ('D:\GitHub\database-accessor\lib');

use lib ('..\t\lib');

use strict;

use Test::More tests => 5;


BEGIN {

    use_ok('Database::Accessor');

    use_ok('Data::Test');

}

my $da = Database::Accessor->new();

ok( ref($da) eq 'Database::Accessor', "DA is a Database::Accessor" );

ok($da->_ldad->{'Data::Test'} eq 'Database::Accessor::DAD::Test','Load of DAD Test sucessful');

my $result;

my $fake_data_source = Data::Test->new();

ok($da->retrieve( $fake_data_source, $result ));

Now the only special thing I did was a quick trick with

use lib ('..\t\lib');

to add the Data::Test and Database::Accessor::DAD::Test to the name-space path. Now thanks to the code in my Accessor.pm I will seek out that DAD::Test and load it up when I start. To prove this I added in this test;

ok($da->_ldad->{'Data::Test'} eq 'Database::Accessor::DAD::Test','Load of DAD Test sucessful');

Now I run my tests and I get this

Attribute (View) does not pass the type constraint because: Validation failed for 'Object' with value undef at C:\Dwimperl\perl\site\lib\Moose\Object.pm line 24
Moose::Object::new('Database::Accessor::DAD::Test', 'HASH(0x53678dc)') called at D:\GitHub\database-accessor\lib\Database\Accessor.pm line 119
Database::Accessor::retrieve('Database::Accessor=HASH(0x45f0b14)', 'Data::Test=HASH(0x536830c)', undef) called at 20_dad_load.t line 21
# Looks like you planned 5 tests but ran 4.
# Looks like your test exited with 255 just after 4.

So something is not right and I quickly noticed that 'View' does not match on any of the attributes in Accessor.pm as they are all lowercase, so I know this is an error someplace in the Database::Accessor::Roles::DAD and a quick look at that I have;

has View => (

    is     => 'ro',

    isa    => 'Object',

);

So there is a type mismatch here, as that 'View' should be a 'Element' type to match the same type in the original attribute, something I am going to have to fix.

Even at this early stage this test has proved useful. First it points out a programming error I did (not changing the types in my role), it also indicated that I should rearrange my test cases. I will have to test my Database::Accessor::Roles::DAD to make sure it is ok before I test anything with a DAD.

So I think I am going to have to do some more moving of things about.