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 Wednesday 23 Dec 2009 15:42:01 sawyer x wrote: > On Wed, Dec 23, 2009 at 1:30 PM, Shlomi Fish 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 Wed, Dec 23, 2009 at 1:30 PM, Shlomi Fish 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 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 Tue, 22 Dec 2009 22:05:40 + Ben Morrow 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
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
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
