in reply to Re^2: Developing a module, how do you do it ?
in thread Developing a module, how do you do it ?

An alternative idea for having "non-boolean tests" directly in the source. What i don't like about it, is that it makes the source less readable : it becomes harder to search the interesting parts of the code.

I think you got the wrong end of the stick about this.

In the normal way of things, a module, Your::Thing.pm, looks like this:

package Your::Thing;

## The subroutines and stuff that implement your module

1; ## finish with a true value to satisfy require/use

[download]

And the tests live in a bunch of .t files.

The "alternative idea" is that Your::Thing.pm looks like this:

package Your::Thing;

## The subroutines and stuff that implement your module

return 1 if caller; ## return a true value and exit when loaded as a m
+odule
package main;

### Write tests that use Your::Thing here.

...

[download]

You use the module in the normal way via use or require, and it works exactly as with the 'usual way' above.

To run the tests, you type:

>perl \Perl\site\lib\Your::Thing.pm

[download]

And the code that comes after the return 1 if caller; statement gets run. It really is as simple as that.

And whilst the tests and code exist in the same file, the module code is above that line, and the tests are below it. There is no interleaving. Nothing is "less readable". Nothing is "harder to search" for.

Indeed, maintenance is greatly simplified by having the code and tests within the same file.

Try it. You'll never go back :)

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Replies are listed 'Best First'.
Re^4: Developing a module, how do you do it ?
by chromatic (Archbishop) on Mar 03, 2012 at 03:54 UTC
    Indeed, maintenance is greatly simplified by having the code and tests within the same file.

    It can be, depending on the project.

    I'm no longer a fan of the "you must have one .t file for each logical module in your program" rule. I prefer my test files to have their own logical relationships, where each file tests one function of the program in a particular way. For example, in the Pod::PseudoPod::DOM test suite, I have separate subdirectories for each type of formatter and separate test files for each category of transformation (escapes, environments, block-level items, tables, and so on).

    This does require a little bit of testing infrastructure, but organizing more than a few tests is like organizing more than a few lines of code. You choose the best option based on what you're doing and you change it to work better when it becomes necessary or obvious.

[reply]

      PseudoPOD?! Really? I mean, Really??

      Update: I mean: Really, really!??

      You really have nothing better to do with your time? You've never heard of Tex. and postscript and PDF and Word and HTML?

      I'll stop.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?
[reply]

        You assume too much. I've written TeX and PostScript by hand. I've also written assembly by hand. I wrote my own PDF generator too.

        I'm not doing that again.

        (Doesn't mean POD is any good at tables, but what is?)

[reply]

In Section Seekers of Perl Wisdom