How to test an abstract builder?

Hi Perl blogosphere. Yes, today I’m talking into the camera.

I’m very pleased to have had my Perl Foundation Grant to develop Alien::Base funded and I have redoubled my efforts.

I have high hopes for this module as a tool to help authors provide the C libraries they need through CPAN far more easily than hand rolling an Alien:: module. As such I feel a deep urge to ensure that Alien::Base is robustly tested.

Unfortunately I’m finding that testing such a module is rather hard. Alien::Base is a very abstract concept. It only makes any sense when it is used as the base class for some other Alien:: module, and futher, THAT module is only fully realized when it is used by some other module which needs that C library.

So far I have been using a version of Alien::GSL which has been retooled to use Alien::Base, further I am working on providing a simple C library which can be distributed with A::B as another test case. Still this seems rather hackish. Of course I test what I can separately, but much of the functionality comes when used “all together”.

Anyway, I’m not asking for any magic beans, but perhaps someone knows of a secret sauce or example. Thanks!


With a couple changes to my test-case library’s Build.PL, I can now ‘do-load’ that file and get the M::B object back. From there I can dispatch the build commands, but still have access to the builder object. This is much better than system('perl Build.PL') from inside a .t file, and worlds better than running Build.PL by hand.

Ok I’m feeling a lot better now. Still if you have any suggestions, I’m all ears!


I do think your approach of bundling a small C library with Alien::Base is the best way.

Maybe a library implementing the memfrob encryption algorithm?

You might want to try DistGen for test. It’s used for Module::Build’s and Module::Build::Tiny’s tests.

Leave a comment

About Joel Berger

user-pic As I delve into the deeper Perl magic I like to share what I can.