Sheol has asked for the wisdom of the Perl Monks concerning the following question:

Well, I've read up a little on Python (easy, easy... I didn't come here to start a langauge war), and one thing I've noticed a lot in their teachings, is in files that are meant for including in other files have a little something at the bottom of the code that goes something like:

if __package__ eq __main__:
   # do stuff to test to see if package is working.

[download]
(elaboration '(the young monk is easily excited) '(I would like to be able to do this with perl as well as Python. The solution...)) I would guess it would be one of: 
if($main == "hardcoded::package::name") { }
if($main == $PROGRAM_NAME) { }
if($main->isa("hardcoded::package::name")) { }

[download]
However, I am sure all of those are flawed. I am also sure t here is a better way to "emulate" what Python programmers do in perl. For those of you unfamilure with this proramming practice, it is done so each portion of a project can be tested indepedandtly. However the same code that tests it, does not get ran when it is included. Now, as far as I am concerned running: 
$debug && print "some code";
$debug && print "some more code"

[download]
As that is just messy. This would make debugging my stuff a lot easier. Thank you kindly

Replies are listed 'Best First'.
Re: Self Testing Modules
by demerphq (Chancellor) on Dec 18, 2005 at 00:21 UTC

    The perl version of that is 

    unless (caller) {
...
}

    [download]

    If you put a block like that in the main part (ie, not in a sub, preferably right before the true value that all modules end with) of a .pm file you can do 

    perl Module.pm

    [download]

    And it will execute, but if its loaded via use Module; it won't.

    I think thats what you are after anyway.

    You _could_ use if ($0 eq __FILE__) { ... } I suppose, but the problem there is that __FILE__ probably will be fully qualified, but $0 might not be.

    Having said all of that, module test code in perl doesnt normally go in such a block. Its more for quick debug/test code that you use during development. If you want to test your code properly you should use the test framework that comes with perl.

    Update: switched the 'if' to an 'unless' as per happy-the-monks correction.

    ---
    $world=~s/war/peace/g

[reply]
[d/l]
[select]

      if (caller) {
...
}

      [download]

      All right except demerphq got it the wrong way round.
      What he meant was:

      unless ( caller ) {
    # here go the tests that are only called when the module is run as
+:
    # perl Module.pm
}

      [download]

      It's part of my cargo cult programming style. You know the documentation of caller, as you've already written in this thread.

      Cheers, Sören

      Update: I just saw a similar thing on a thread at German language Perl-Community.de.
      eserte writes:

      return 1 if caller; # end of the module's own code

# Test Code goes here

      [download]

[reply]
[d/l]
[select]

        Doh. Doh. Doh.

        happy-the-monk is correct, i got it backwards. :-(

        ---
        $world=~s/war/peace/g

[reply]

      Thank you for your prompt response. I think that is what I want.

      To learn more about this "caller" would I just be fine with a `perldoc -f caller` followed by a `perldoc -q caller` or is there another section of perldoc I should check as well or instead?

      I missed the second part

      As per using the building debuging suite, if I am thinking of what you are thinking of, that kind of won't really work. You're talking about `perl -c` and `perl -d` right? That really won't work in my case. Generally I've found those features really useful when the program is meant to run and stay running.

      However for some of what I plan on doing, will require a request response model. So the script will be run in many instances where it is easier just have trip alarms at certain points while working on it.

      This may sound like it contradicts what I am going for here, as to use caller, I'll need some fake data. However the module using it will be fairly simple. Only really done to keep things tidy and clean/easy to read for moshes.

      For what I am planning, I find it would be easier to do it this way, and I am still not a wizard with the debugging suite yet.

      However this train of thought brings up another thing I have been thinking over a few days.

[reply]

        Happy-the-monk was correct, its actually unless(). And what i meant was to set up a proper test framework using h2xs, Test::More and Test::Harness. Then you can build a conventional Perl test framework, so eventually your module can be uploaded to CPAN (even if it never is, using the framework is still a big asset).

        ---
        $world=~s/war/peace/g

[reply]
Re: Self Testing Modules
by eyepopslikeamosquito (Archbishop) on Dec 18, 2005 at 21:32 UTC

    Now, as far as I am concerned running: 
    $debug && print "some code";
$debug && print "some more code"

    [download]
    As that is just messy.

    Indeed. To make tracing code less messy, have a look at TheDamian's Smart::Comments module.

[reply]
[d/l]
Re: Self Testing Modules
by eyepopslikeamosquito (Archbishop) on Dec 18, 2005 at 21:21 UTC

    Though you can do that in Perl, I can't recommend it as a "best practice" (in either Perl or Python) because it doesn't scale well as your module (and its tests) grow.

    The recommended testing solution for Perl is Test::More (start by reading Test::Tutorial), and for Python it's PyUnit.

[reply]
      it doesn't scale well as your module (and its tests) grow

      Would you explain that?

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

        When writing a lot of tests, having one large monolithic block of tests can become difficult to manage. For example, with Test::More, it is more manageable to write many small .t files, rather than one large one.

[reply]

Back to Seekers of Perl Wisdom