First, I simply understand that the machinery for getting modules installed is rather complex and must deal with differences in environments while implementing a data structure in Perl (without using XS) can easily be done in a way that is not sensitive to environment differences. So, the module having worked for one person while failing for another was simply more likely to be a problem with the installation machinery than with the functionality of a module for implementing a data structure.

So I downloaded Heap::Simple::Perl and ran "perl Makefile.PL" and then "make test" (actually "dmake test" in this case) under Windows and saw that all of the tests failed but the error messages were about not even being able to load modules. So the problems for my instance had nothing to do with the functioning of the module (since it seemed that the module under test wasn't even being found to be loaded). I find that actually reading error messages is very often useful in getting past problems (and I see even experienced software developers very often skip that simple step).

Next, I looked at the published test results for the module and saw that the majority of them pass. This reinforced my initial assessment. Next, I noticed that the first few failures I found listed were all on Windows. So the most likely explanation was that the process of getting the tests to run correctly was due to a quirk of Windows or of a common build of Perl on Windows. Update: Actually, taking a couple more minutes looking this morning, http://matrix.cpantesters.org/?dist=Heap-Simple-Perl+0.14 shows that the problem is newer versions of Perl and (as noted in another reply) with unit tests testing fragile things (unit tests being more sensitive to environment changes is another common problem).

Next, since many modules are able to get tests to run fine under Windows, I was curious if the module was doing something unusual or complex in how it arranged for the tests to be run. Looking at Makefile.PL, there was certainly some extra complexity there (at least in part to prompt the user for whether or not they wanted benchmarks to be run). Though, it still looked like it boiled down to a fairly vanilla invocation of ExtUtil::MakeMaker. So it'd take me more time to dive into that complexity to see if I could find a likely source for the failures on Windows, and I had no plans to debug to that level.

Finally, I noticed that the "% pass" value for the module was 100% for several prior versions of the module. So just asking for a slightly older version to be installed would likely make all of the problems go away. And then reading the Changes file showed that those changes were all about how installation was done and not about what the module actually does, so it seemed extremely likely that both new and old versions of the module would work just fine but that slightly old versions of the module would likely install w/o issues.

The failing tests in question seems to count the number of magic fetches (through tie), and the number of times a magic value callback is called has varied and is more a Perl implementation specific thing. It doesn't really seem to impact the correctness of the module.

I learned how to get to the module tests in CPAN from your response, and I didn't know how before, so that's a bonus.

I guess it's a comment on test quality of CPAN modules, or perhaps on the pass-fail nature of testing. The author decided that something matters enough to test (and therefore fail installation when it does not work), when it really doesn't matter to the actual operation of the module. Or so it seems ;)

The take-away, for me anyway, is I have the ability to inspect the test(s) that are telling me an installation failed, and I might be be able to determine that they relate to conditions that don't impact me. I might not also, depending on the complexity of the module and tests. But I'll never know if I don't look. That's just part of CPAN due diligence.

Dum Spiro Spero