in reply to Automatic POD for test cases?

I like the idea very much, but calling a module that mostly fails on modern perl and introduces 28 non-core dependencies "best thing since sliced bred" seems to be a slight exaggeration.

Yes, the test failures seem to be related to the harness, but the mere fact that this has happened since the release of 5.10 and the author didn't react so far doesn't shed a very good light on the module.

I'm all for code reuse, but I wouldn't want to inflict those dependencies on users of my code just to improve testing a bit. It might be an option for tests that are only run in author mode, though.

Replies are listed 'Best First'.
Re^2: Automatic POD for test cases?
by Anonymous Monk on Aug 12, 2009 at 17:57 UTC
    I'm the module author so expect some bias.

    With all due respect due to your opinion, "no non-core dependencies" is the most silly claim ever because all the modules making the claim are by definition non-core. This said, I am guilty of having many dependencies in most of my modules (I may get better at some point but I frankly doubt it). I still hope you can find one that may be usefull.

    I totally agree with you that the module should be only used in author test mode to make it more manageable for end users.

    There was little I could do for the errors on 5.10.0 because the errors are probably not in my module. The error on a 5.10.0 are different on bsd and linux and to quote someone who's much better than I am with testing "<Schwern> If its some sort of memory corruption voodoo that would make sense". It does pass testing in 5.10.1 and 5.11.0 wich hopefully qualify for modern perl versions.

    There are still a few things I'd like to implement in POD::Tested (also check the twin module Test::Cookbook). I'm impatiently longing for community input.

    I hope this does shades some brighter light.

    Cheers, Nadim.
[reply]

In Section Meditations