how do you build and test your modules locally before publishing

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

I've been trying my hand at making a simple perl module.

Now, so far I write this on the top of the file where I want to use the module to test it out:

use lib("path_to_my_module/lib");
[download]

Everything works ok till I try to run the default tests (generated by module starter). I get:

#   Failed test 'use Dancer::Plugin::Foo;'
#   at t/00-load.t line 12.
#     Tried to use 'Dancer::Plugin::Foo'.
#     Error:  Can't locate Dancer/Plugin/Foo.pm

It fails this test:

BEGIN {
    use_ok( 'Dancer::Plugin::Foo' ) || print "Bail out!\n";
}
[download]

Thats all because the path is not right. But, even if I use use lib(path to_module) it doesn't work.

How do you guys usually use and test your modules locally before publishing them? How should I get the test to pass? I can't just add a use lib there!

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

Replies are listed 'Best First'.
Re: how do you build and test your modules locally before publishing by davido (Cardinal) on Dec 31, 2012 at 02:27 UTC
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	[reply] [d/l] [select]
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]
Re: how do you build and test your modules locally before publishing by Anonymous Monk on Dec 31, 2012 at 02:29 UTC
Right before releasing I use `perl -e "$ENV{RELEASE_TESTING}=1; system $^X, 'Makefile.PL'; system 'dmake disttest'; "` because dmake is my `perl -V:make` and my shell is cmd.exe, so I can't `RELEASE_TESTING=1 make disttest` ;) Before that I use `prove -Ilib t\03specific.t` or `dmake test` or `prove -vb t\04specifi.t` depending if i'm starting from scratch, fixing a specific bug, writing a new test, verifying a bug, or whatever ... type once then up-arrow+enter to repeat from my commandline history Pretty much regular stuff. I don't like the editor integration(F5/Ctrl+F7/whatever) or file watchers(run test on save, autoprove) See also Starting a module with Module::Starter How to make a CPAN Module Distribution José's Guide for creating Perl modules RFC: How to Release Modules on CPAN in 2011 Do Pure Perl CPAN packages really need to use ExtUtils::Command::MM? Why I hate Dist::Zilla What are all the possible ways to deploy Perl code on multiple servers?	[reply] [d/l] [select]

Back to Seekers of Perl Wisdom