[tpm] Makefile and proper use of t/*.t

[James E Keenan]

On Sep 10, 2009, at 9:08 AM, Madison Kelly wrote:

> Hi all,
>
>   This is a follow-up to my last question on testing. I followed  
> Adam and Michael's advice and read up on and became comfortable  
> with Test::* (Harness, Tutorial, Simple and More, specifically). My  
> test code is much cleaner and more concise now, so thank you again.
>
>   The two topic I still need help on are;
>
> Second -
>
>   The last thing I need to do before I can even think about getting  
> my modules on CPAN is to learn how to create a Makefile.pl. I've  
> looked at other modules for examples, but none have any comments I  
> found useful. I know that there is a reference to using h2xs to  
> create a framework which sets up a module from the beginning, but  
> my modules are already well under way. Also, I'd like to understand  
> the theory better so that my talk next month will be as complete as  
> possible.

You only *really* need h2xs if you're going to be creating C  
extensions with the XS glue language.  That almost certainly is not  
the case here.  Instead you should install CPAN distro  
ExtUtils::ModuleMaker, then use its 'modulemaker' command-line  
utility to prompt you to create the directory and file structure  
needed for CPAN.  Here's a slideshow I prepared on the subject a  
couple of years back.

> First -
>
>   I couldn't find a good overview of the proper use of the t/*.t  
> files. For now, I've created a base 'test.pl' in the root of my  
> module that makes sure I can do the basics of loading my  
> "parent" (main sibling) module. Then it uses 'require_ok(t/Foo.t)'  
> for each of the test files. The exact name of each *.t file matches  
> the corresponding *.pm file it tests.

Look at the test suite for ExtUtils::ModuleMaker.  Or, for simpler  
cases, the test suite for any of my distros on CPAN:  http:// 
search.cpan.org/~jkeenan/.

People take different approaches to how they name/number their .t  
files.  Generally speaking, I create one .t file for each exported  
subroutine or public method.   But other approaches are quite  
plausible as well.

Jim Keenan