Re: how do you build and test your modules locally before publishing

prove has the "-b" and "-I" switches, which can be used to specify where to find the library(s) that the tests need to use. For example, if MyMod::Foo hasn't been built yet, and just exists in a distribution tree such as:

MyMod-Foo/lib/MyMod/Foo.pm

...and my tests are in...

MyMod-Foo/t/*.t

Then I could 'cd' into MyMod-Foo, and execute the following:

prove -Ilib
[download]

This assumes the module doesn't require any special build process (for example, no XS, no Makefile.PL trickery). Or if my module has a Makefile.PM that conforms to the normal module building standards:

perl Makefile.PL
make
prove -b
[download]

...which first builds the module into a "blib" (build lib) directory, and then tells 'prove' to look in the MyModule-Foo/blib/ directory for the temporary built version of the module.

Perl also has the -I switch (that's -I as in Include -- <<corrected-thanks tobyink>> -- documented in perlrun. So once again, I could 'cd' into MyModule-Foo/ and type: perl -Ilib t/00-load.t, again assuming that the development version of the module resides in MyModule-Foo/lib/MyModule/Foo.pm.

If the module is standards conforming, you can use a version of the mantra: perl Makefile.PL, make, and make test, or perl Build.PL, Build, and Build test. Many authors also use environment variables to control what tests run. Additional information on distribution maintenance commands can be found in ExtUtils::MakeMaker

Dave

Comment on Re: how do you build and test your modules locally before publishing Select or Download Code

Replies are listed 'Best First'.
Re^2: how do you build and test your modules locally before publishing by tobyink (Canon) on Dec 31, 2012 at 11:40 UTC
Huh? On my system at least, the perl option for setting a library path is an upper-case "i": `perl -Ilib t/00-load.t` [download] That is, the same as `prove`. The lower-case "L" option (`perl -l`) is line end processing for one-liners. `prove -l` (lower-case "L") is a useful shortcut for `prove -Ilib`. `perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'`	[reply] [d/l] [select]
Re^3: how do you build and test your modules locally before publishing by davido (Cardinal) on Dec 31, 2012 at 17:21 UTC
Corrected. ...sometimes things that are "force of habit" become difficult to explain. And somehow in so-doing, I managed to confuse myself. :) Thanks for the nudge. Dave	[reply]
Re^2: how do you build and test your modules locally before publishing by gideondsouza (Pilgrim) on Dec 31, 2012 at 03:57 UTC
Thanks very much for your reply davido. Exactly what I was looking for One more little query, the `perldoc` command doesn't seem to have a -I switch. How should I test if the POD I've written looks ok? How is it usually done?	[reply] [d/l]
Re^3: how do you build and test your modules locally before publishing by tobyink (Canon) on Dec 31, 2012 at 11:35 UTC
`perldoc` allows you to provide a file path rather than a module name... `perldoc File::Spec perldoc lib/Foo/Bar.pm` [download] I tend to view my pod in an 80x24 terminal to check there's no ugly line wrapping issues at that size. I also check with Test::Pod and Test::Pod::Coverage. `perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'`	[reply] [d/l] [select]
Re^3: how do you build and test your modules locally before publishing by davido (Cardinal) on Dec 31, 2012 at 04:01 UTC
Test::Pod, and Test::Pod::Coverage, if memory serves. Also, Perl::Critic: One of the elevated levels of whining will grouse at you if your POD is missing sections common to modules. I think Test::Kwalitee does some POD diving too, but half the time I can't even get it to install all of its deps. Test::Kwalitee and Test::PerlCritic should always be "author-only" tests, by the way. Dave	[reply]