in reply to Re^5: When C<use Module;> *not* the same as C<require Module; import Module;>?
in thread When C<use Module;> *not* the same as C<require Module; import Module;>?

That's one (of an ever extending list) of reasons that I dislike both the concept and implementation, and so do not use, the Test::* suite of modules.

Test code should not itself impose additional runtime constraints and requirements. If it does, then you end up having to write testcode to test the testcode as well as the testcode to test the code under test.

Testing is good. But in my opinion, and I realise that many (most?) will disagree with me, most of the mechanisms I've seen used for performing testing of Perl, and particularly those of the Test::* suite of modules I've looked at, are too invasive and impose too many constraints, requirements and dependancies.

That's not a well-formed or properly elaborated explaination. Maybe I'll get around to thinking it through properly and writing it up one day.

Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.
  • Comment on Re^6: When C<use Module;> *not* the same as C<require Module; import Module;>?

Replies are listed 'Best First'.
Re^7: When C<use Module;> *not* the same as C<require Module; import Module;>?
by chromatic (Archbishop) on Jan 08, 2005 at 20:58 UTC
    Test code should not itself impose additional runtime constraints and requirements.

    I'm having a difficult time reconciling the notion of a library that provides additional behavior yet does not impose any additional constraints or requirements. Please do consider writing up your views more formally; I'm genuinely curious as to what you do mean.

[reply]
Re^7: When C<use Module;> *not* the same as C<require Module; import Module;>?
by itub (Priest) on Jan 08, 2005 at 23:25 UTC
    This is getting off-topic, but I don't think Test::* imposes a heavy burden. My usual testing policy is the following:
    1. Use Test::More freely. It comes with perl 5.8 and is so widely used that it is not an extravagant request by any means.
    2. Optionally use other testing modules (such as Test::Pod and Test::Exception), but don't require them. Test if they are installed and skip the tests if they are not. This only requires a couple lines of code.

    Another possible solution is to bundle the testing modules with your distribution. Module::Install provides a mechanism for that, and the user does not need to install any modules before or after the tests.

[reply]

      Off topic for the origins of this thread, but merlyn laid my original question to rest quite succinctly. Otherwise, I think that testing, and discussion of testing methodology is very germaine.

      It's not just the dependancy issue that I baulk at.

      I also have a problem with

      1. The design of their interfaces.
      2. The way they report failure.
      3. The testing methodology that they encourage.
      4. And the all-in-one, everything-gets-tested-every-time aspect of the way they are (generally) used.

      That's kind of vague I know, almost deliberately. I did start to try expand it a little, but I need to take my time and think the whole think through before writing it down for public scrutiny.

      As I have been asked to elaborate, I will take a few days to write it down and clarify my own thinking before posting.

      Examine what is said, not who speaks.
      Silence betokens consent.
      Love the truth but pardon error.
[reply]

In Section Seekers of Perl Wisdom