For some real life examples of what I think you are after, look how the Crypt::* block cipher modules work, see Crypt::CBC for the root module. Or as another example, DBI and its DBD::* drivers. Both of these root modules serve as a gateway to the other, "driver" modules.

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]

irrespective of whether $obj is a Foo::Bar or a Baz::Quux; these two classes don't even need to have anything in common, all that is necessary is that both know how to toot. So, perhaps you're just trying too hard...?

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.