Section 17.6. Testing Object-Oriented Features

17.6. Testing Object-Oriented Features

For object-oriented modules , we want to ensure that we get back an object when we call the constructor. For this, isa_ok( ) and can_ok( ) are good interface tests:

 use Test::More 'no_plan'; use Horse; my $trigger = Horse->named('Trigger'); isa_ok($trigger, 'Horse'); isa_ok($trigger, 'Animal'); can_ok($trigger, $_) for qw(eat color); 

These tests have default test names, so our test output looks like this:

 ok 1 - The object isa Horse ok 2 - The object isa Animal ok 3 - Horse->can('eat') ok 4 - Horse->can('color') 1..4 

Here we're testing that it's a horse, but also that it's an animal, and that it can both eat and return a color.^[*] We could further test to ensure that each horse has a unique name:

^[*] Well, we're testing to see that it can('eat') and can('color'). We haven't checked whether it really can use those method calls to do what we want!

 use Test::More 'no_plan'; use Horse; my $trigger = Horse->named('Trigger'); isa_ok($trigger, 'Horse'); my $tv_horse = Horse->named('Mr. Ed'); isa_ok($tv_horse, 'Horse'); # Did making a second horse affect the name of the first horse? is($trigger->name, 'Trigger', 'Trigger's name is correct'); is($tv_horse->name, 'Mr. Ed', 'Mr. Ed's name is correct'); is(Horse->name, 'a generic Horse'); 

The output of this shows us that the unnamed Horse is not quite what we thought it was.

 ok 1 - The object isa Horse ok 2 - The object isa Horse ok 3 - Trigger's name is correct ok 4 - Mr. Ed's name is correct not ok 5 #     Failed test (1.t at line 13) #          got: 'an unnamed Horse' #     expected: 'a generic Horse' 1..5 # Looks like you failed 1 tests of 5. 

Oops! Look at that. We wrote a generic Horse, but the string really is an unnamed Horse. That's an error in our test, not in the module, so we should correct that test error and retry. Unless, of course, the module's specification actually called for 'a generic Horse.'^[] You shouldnt be afraid to just write the tests and test the module. If you get either one wrong, the other will generally catch it.

^[] And, well find that the tests not only check the code, but they create the specification in code form.

You can even test the use with Test::More when you want to ensure that the module loads correctly:

 use Test::More 'no_plan'; BEGIN{ use_ok('Horse') } my $trigger = Horse->named('Trigger'); isa_ok($trigger, 'Horse'); # .. other tests as before .. 

The difference between doing this as a test and doing it as a simple use is that the test won't completely abort if the use fails, although many other tests are likely to fail as well. It's also counted as one of the tests, so we get an "ok" for free even if all it does is compile properly to help pad our success numbers for the weekly status report.

We put the use_ok inside a BEGIN block so any exported subroutines from the module are properly declared for the rest of the program, as recommended by the documentation. For most object-oriented modules, this won't matter because they don't export subroutines.