Hmm. I can certainly see the goodness of packaging up a module like this: if your colleagues scattered around the world are all using "perl -MCPAN" and have it set up nicely to follow dependencies, then consistency among all the test locations is assured. And thank you very much for posting such a clear and simple example of packaging a module.

As for putting the actual network test logic into the "make test" part of the build/install process -- as opposed to making it part of an executable perl script -- I suppose there might be good reasons for that... e.g. if this was a "one-shot" problem and you don't expect to have to run this sort of distributed test again, then you did the right thing by not leaving a stray executable laying around on everyone's system. Likewise, if you are going to have to do this sort of test again, but next time the parameters (host list, protocol list, or whatever) will be different, it might be just as well to treat it as a new "install/test" process, rather than sending just an updated executable (when folks probably haven't used the original for months) and hoping that nobody made unexpected changes to their perl configurations.