Re: Test-only code
On 12/23/2009 03:30:49 AM, Shlomi Fish wrote: On Wednesday 23 Dec 2009 00:05:40 Ben Morrow wrote: Quoth ge...@hughes.net (Geoffrey Leach): I'm working on a new release of Getopt::Auto. There's a fair amount of code in the module that applies only to the tests. It would be nice if that code was not in the installed module. Any suggestions? Given that Perl allows you to put code in any package from any module, can you just have a module in your t/ dir that implements the testing hooks? Personally I like to put such modules in the t:: namespace, since tests are always run from the module build directory, so I might call it t::Hooks or some such. What I normally do is put it under t/lib (say t/lib/Config/IniFiles/TestFiles.pm) and then do: use lib ./t/lib; use Config::IniFiles::Testfiles; use Config::IniFiles::OtherHelperModule; # Etc. This is cleaner than calling the module itself t::, as modules that start with a lowercase letter should be pragmata. Regards, Shlomi Fish Thanks to Shlomi and all who replied. I elected to use the 'use lib ./ t/lib' paradim and then discovered something rather unusual. Getopt::Auto has code that is run in the CHECK and INIT blocks as well as an import() subroutine. Appartently this interacts somehow with the subsidiary lib. For example, require TestSupport; ... TestSupport::foo() results in Undefined subroutine TestSupport::foo ... but bare foo() works fine. TestSupport.pm does not export. Perhaps I can figure this out one day :-)
Re: Test-only code
On Tue, 22 Dec 2009 22:05:40 + Ben Morrow b...@morrow.me.uk wrote: Personally I like to put such modules in the t:: namespace, since tests are always run from the module build directory, so I might call it t::Hooks or some such. +1 I often do similar; usually I'll have a t::TestFoo or t::MockBar in there. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Test-only code
On Wednesday 23 Dec 2009 00:05:40 Ben Morrow wrote: Quoth ge...@hughes.net (Geoffrey Leach): I'm working on a new release of Getopt::Auto. There's a fair amount of code in the module that applies only to the tests. It would be nice if that code was not in the installed module. Any suggestions? Given that Perl allows you to put code in any package from any module, can you just have a module in your t/ dir that implements the testing hooks? Personally I like to put such modules in the t:: namespace, since tests are always run from the module build directory, so I might call it t::Hooks or some such. What I normally do is put it under t/lib (say t/lib/Config/IniFiles/TestFiles.pm) and then do: use lib ./t/lib; use Config::IniFiles::Testfiles; use Config::IniFiles::OtherHelperModule; # Etc. This is cleaner than calling the module itself t::, as modules that start with a lowercase letter should be pragmata. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Original Riddles - http://www.shlomifish.org/puzzles/ Bzr is slower than Subversion in combination with Sourceforge. ( By: http://dazjorz.com/ )
Re: Test-only code
On Wed, Dec 23, 2009 at 1:30 PM, Shlomi Fish shlo...@iglu.org.il wrote: What I normally do is put it under t/lib [...] Module::Starter is an example of this. I believe Module::Build is, too. This is cleaner than calling the module itself t::, as modules that start with a lowercase letter should be pragmata. cleaner +1.
Re: Test-only code
On Wednesday 23 Dec 2009 15:42:01 sawyer x wrote: On Wed, Dec 23, 2009 at 1:30 PM, Shlomi Fish shlo...@iglu.org.il wrote: What I normally do is put it under t/lib [...] Module::Starter is an example of this. I believe Module::Build is, too. Well, I am to blame for the t/lib modules in Module::Starter , as it was me who added this test code there. I used the t/lib paradigm in several other modules before (not Module::Build though, which I didn't do a lot of extensive work on, yet), but think this convention predates me. In any case, it can be t/test-support-lib or whatever you want - M::B/EU::MM/etc. won't complain, and won't install anything that's not under lib/ [1] For HTML-Widgets-NavMenu I used to have some testing support code under $dist/HTML/ (instead of $dist/t/lib/HTML) but I recently converted away from it. This is cleaner than calling the module itself t::, as modules that start with a lowercase letter should be pragmata. cleaner +1. Indeed. +1 here too. Please don't do use t::lib::MyModule::Support; Regards, Shlomi Fish [1] - Unless you have some modules in the top-level of the directory like putting Bar.pm in the top-level for Foo::Bar. But this is an evil relic of ancient Perl modules and should not be used any more. -- - Shlomi Fish http://www.shlomifish.org/ The Case for File Swapping - http://shlom.in/file-swap Bzr is slower than Subversion in combination with Sourceforge. ( By: http://dazjorz.com/ )
Re: Test-only code
On Dec 22, 2009, at 10:33 PM, Geoffrey Leach wrote: I'm working on a new release of Getopt::Auto. There's a fair amount of code in the module that applies only to the tests. It would be nice if that code was not in the installed module. Any suggestions? Maybe persona.pm (from CPAN, by yours truly) would make sense for you. It *would* however add a dependency, which may not be what you want. Liz
Re: Test-only code
Quoth ge...@hughes.net (Geoffrey Leach): I'm working on a new release of Getopt::Auto. There's a fair amount of code in the module that applies only to the tests. It would be nice if that code was not in the installed module. Any suggestions? Given that Perl allows you to put code in any package from any module, can you just have a module in your t/ dir that implements the testing hooks? Personally I like to put such modules in the t:: namespace, since tests are always run from the module build directory, so I might call it t::Hooks or some such. Ben
