What's so strange about Perl is that you don't need subclasses of a common base class, in order to use "virtual methods", unlike in many other OO languages. In other words, in Perl you can do

$obj->toot(@args)
[download]

Alternatively, can also think about "delegating" methods, where you pass on method calls to embedded objects. Class::Delegate is one obvious example of such a delegation module, but I'm no expert in this area and I don't know it's the best you can find.

As for the tests: yes there are ways to skip tests if a module isn't installed at test time. That won't prohibit code using a later installed "driver", perhaps even one that didn't exist yet, at the time the master module was installed. There simple is no connection between the tests and any later use of the code.

The only problem is, when adding the driver later, that it won't have been tested. Perhaps you should include your tests with the driver, or if it's not a module specifically created to work with yours, with an interface compatibility layer module. The latter could have contain no actual code apart from some stubs, like a module loader, and the tests.

Using isa:

if (UNIVERSAL::isa($ref, 'Foo::Bar')) {
   #...
} elsif (UNIVERSAL::isa($ref, 'Baz::Quux')) {
   #...
}
[download]

Query your object to see if it provides the necessary API. If so, use it. If not, try the fallback. If that doesn't exist, bitch at the user.

sub fulfills_interface_foo {
    my $self = shift;
    return $self->can( ... )
        and $self->can( ... )
        and $self->can( ... )
        and $self->can( ... );
}
[download]

Presumably, you have a lot of code that is common between the two cases (else it likely wouldn't make much sense to combine these case into a single module).

So, best would be to factor out the code that isn't the same (normally you 'factor out' what is the same). In the places where these chunks were factored out, you put a $obj->Method(...). Now write Method() for the two cases but both wrapper classes have the same interface.

After you've defined the two versions of each method, you'll have two classes. Each is a wrapper for one of the external classes.

A common next step would be to make @Blarg::Wibble::Foo_Bar::ISA= 'Blarg::Wibble' and then have Blarg::Wibble::new() decide which subclass to bless into based on the type of argument passed in.

But OO old-timers learn to be suspicious of inheritance. And this is a perfect example of a trap where inheritance makes your design a bit more fragile and harder to extend.

Better is just to have Blarg::Wibble::new() create and hold a Blarg::Wibble::Foo_Bar-wrapper that it uses.

For testing, you want to 'skip' tests in the case you described. How you skip tests depends on the testing module you used. For example, Test::More offers the following somewhat dubious construct:

   SKIP: {
      skip $why, $how_many
         if  ! eval { require Foo::Bar; 1 };
      # tests go here
   };
[download]

For your case, I'd probably have a FooBar.t and BaxQuux.t that each use a common test.pm whose import() runs the tests and does skip_all if the passed-in module name can't be required.