Re: Module naming - Test::Import::DontRun
When developing code to include One might think it intolerably rude To use words ungrammatical As a method pragmatical To avoid compilation being screwed :-P On 8 October 2010 00:13, Paul Johnson p...@pjcj.net wrote: On Thu, Oct 07, 2010 at 12:36:41PM +0100, Charles Colbourn wrote: Test::Include::DontRun I'll just point out that any name which includes DontRun rather than Don't::Run has sold its soul and should probably start with Com::ReallyBigCorporation::Enterprise:: Then I'll duck (low) and I will run. -- Paul Johnson - p...@pjcj.net http://www.pjcj.net
Re: Module naming - Test::Import::DontRun
Hi all, It occurs to me that the uses for this could extend outside testing. Looking at CPAN, the root namespace 'Include' already exists, so Include::DontRun would be a viable name, and seems pretty descriptive to me. Anyone got any objections? I've handled the __DATA__ and __END__ cases now. charles. On 8 October 2010 09:25, Charles Colbourn charles.colbo...@googlemail.com wrote: When developing code to include One might think it intolerably rude To use words ungrammatical As a method pragmatical To avoid compilation being screwed :-P On 8 October 2010 00:13, Paul Johnson p...@pjcj.net wrote: On Thu, Oct 07, 2010 at 12:36:41PM +0100, Charles Colbourn wrote: Test::Include::DontRun I'll just point out that any name which includes DontRun rather than Don't::Run has sold its soul and should probably start with Com::ReallyBigCorporation::Enterprise:: Then I'll duck (low) and I will run. -- Paul Johnson - p...@pjcj.net http://www.pjcj.net
Re: Module naming - Test::Import::DontRun
I must admit that I didn't get what you mean. Care to enlighten me with a piece of code, some flow, anything that doesn't make me feel stupid. Nadim.
Re: Module naming - Test::Import::DontRun
Mea Culpa - it wasn't a very clear description.
OK, so perhaps you have a script like this:
###myscript.pl###
doStuff();
doOtherStuff();
sub doStuff{
# things that need testing
}
sub doOtherStuff{
# things you don't want to run
}
__END__
and you don't have the option of wrapping the top level scope
('doStuff();doOtherStuff()') in 'if caller(){}' - maybe it's legacy
code that is running fine in production, and you don't want to modify
it.
The idea is your test script looks like this:
use Test::Import::DontRun qw(myscript.pl);
my $res = doStuff();
cmp_ok($res,eq,Some or other value);
It works very simply, by wrapping the source of 'myscript.pl' in
{last; code }'. There's some complex and potentially slightly
fragile stuff to handle @EXPORT if you want to, but the basic case
works pretty well.
I hope that's clearer. Feel free to say 'what a stupid idea' or 'that
won't work because' incidentally - but so far I've found it pretty
useful.
thanks,
Charles.
On 7 October 2010 09:02, nadim khemir na...@khemir.net wrote:
I must admit that I didn't get what you mean. Care to enlighten me with a
piece of code, some flow, anything that doesn't make me feel stupid.
Nadim.
Re: Module naming - Test::Import::DontRun
OK, I get what you want to do. I have seen this before. My brains being what they are lately, I don't remember where but it was not so long ago. Maybe Andy maybe someone else. Maybe even you ;) So before you go further, you can, if you so wish, look around a bit. I'm sure that other with better memory than I have will help. And, NO, it's not a stupid idea. Nadim.
Fwd: Module naming - Test::Import::DontRun
-- Forwarded message --
From: Charles Colbourn charles.colbo...@googlemail.com
Date: 7 October 2010 10:10
Subject: Re: Module naming - Test::Import::DontRun
To: ebhans...@cpan.org
@Eirik
There's some complex and potentially slightly
fragile stuff to handle @EXPORT if you want to, but the basic case
works pretty well.
Whoops. What would your legacy script(?) use @EXPORT for?
Some of the code I'm testing in our own legacy codebase includes
modules that 'do things' when use'd or require'd, and also export
methods via @EXPORT. My code attempts to handle this by duplicating
the @EXPORT* declarations outside the anonymous scope. It does this
simply by parsing the code and finding the appropriate strings. You
can switch this behaviour off if need be, although I'm tempted to make
it default to 'off' since it may not be as robust as the rest.
(I'd be more concerned about __END__, __DATA__, __FILE__, and __LINE__.
Okay, the latter two could be handled with a #line directive, but to handle
the first two right, it seems you'd have to parse Perl ... or drop the {}s?)
Eirik++ I'd overlooked those. I'll see what I can do with it, write
some test cases etc.
@Nadim
OK, I get what you want to do. I have seen this before. My brains being what
they are lately, I don't remember where but it was not so long ago. Maybe Andy
maybe someone else. Maybe even you ;)
So before you go further, you can, if you so wish, look around a bit.
I've had a dig around CPAN, and sifted through 'Perl testing, a
developers notebook' and not found anything. I think I did bandy this
idea around about 6 months ago, but the version I had then depended on
modifying the legacy code, and was a glorified version of:
{
if (caller()){last}
#code
}
So perhaps that was it? I don't think I posted here about it, but I
may have mentioned it in the CB on Perlmonks, and I definitely floated
the idea past a couple of people. OTOH if there's something around
that does this already, that would save me some work :-)
Re: Module naming - Test::Import::DontRun
Just a passing thought - Test::Import::* suggests the import of data,
rather than code.
The generic name for importing code into the current namespace would
be 'include' I guess, so how about
Test::Include::DontRun
?
On 7 October 2010 10:11, Charles Colbourn
charles.colbo...@googlemail.com wrote:
-- Forwarded message --
From: Charles Colbourn charles.colbo...@googlemail.com
Date: 7 October 2010 10:10
Subject: Re: Module naming - Test::Import::DontRun
To: ebhans...@cpan.org
@Eirik
There's some complex and potentially slightly
fragile stuff to handle @EXPORT if you want to, but the basic case
works pretty well.
Whoops. What would your legacy script(?) use @EXPORT for?
Some of the code I'm testing in our own legacy codebase includes
modules that 'do things' when use'd or require'd, and also export
methods via @EXPORT. My code attempts to handle this by duplicating
the @EXPORT* declarations outside the anonymous scope. It does this
simply by parsing the code and finding the appropriate strings. You
can switch this behaviour off if need be, although I'm tempted to make
it default to 'off' since it may not be as robust as the rest.
(I'd be more concerned about __END__, __DATA__, __FILE__, and __LINE__.
Okay, the latter two could be handled with a #line directive, but to handle
the first two right, it seems you'd have to parse Perl ... or drop the {}s?)
Eirik++ I'd overlooked those. I'll see what I can do with it, write
some test cases etc.
@Nadim
OK, I get what you want to do. I have seen this before. My brains being what
they are lately, I don't remember where but it was not so long ago. Maybe Andy
maybe someone else. Maybe even you ;)
So before you go further, you can, if you so wish, look around a bit.
I've had a dig around CPAN, and sifted through 'Perl testing, a
developers notebook' and not found anything. I think I did bandy this
idea around about 6 months ago, but the version I had then depended on
modifying the legacy code, and was a glorified version of:
{
if (caller()){last}
#code
}
So perhaps that was it? I don't think I posted here about it, but I
may have mentioned it in the CB on Perlmonks, and I definitely floated
the idea past a couple of people. OTOH if there's something around
that does this already, that would save me some work :-)
Re: Module naming - Test::Import::DontRun
On Thu, Oct 7, 2010 at 10:22 AM, Charles Colbourn
charles.colbo...@googlemail.com wrote:
It works very simply, by wrapping the source of 'myscript.pl' in
{last; code }'.
Well, as it seems it does no -import(), but just compiles the code ...
Test::LegacyScript::Compile?
There's some complex and potentially slightly
fragile stuff to handle @EXPORT if you want to, but the basic case
works pretty well.
Whoops. What would your legacy script(?) use @EXPORT for?
(I'd be more concerned about __END__, __DATA__, __FILE__, and __LINE__.
Okay, the latter two could be handled with a #line directive, but to handle
the first two right, it seems you'd have to parse Perl ... or drop the {}s?)
I hope that's clearer. Feel free to say 'what a stupid idea' or 'that
won't work because' incidentally - but so far I've found it pretty
useful.
(I won't call the idea stupid, but in any context where cleaning up the
code is an option, it would be the better one.)
Eirik
Re: Module naming - Test::Import::DontRun
On Thu, Oct 07, 2010 at 12:36:41PM +0100, Charles Colbourn wrote: Test::Include::DontRun I'll just point out that any name which includes DontRun rather than Don't::Run has sold its soul and should probably start with Com::ReallyBigCorporation::Enterprise:: Then I'll duck (low) and I will run. -- Paul Johnson - p...@pjcj.net http://www.pjcj.net
Re: Module naming - Test::Import::DontRun
On Thu, Oct 7, 2010 at 4:13 PM, Paul Johnson p...@pjcj.net wrote: On Thu, Oct 07, 2010 at 12:36:41PM +0100, Charles Colbourn wrote: Test::Include::DontRun I'll just point out that any name which includes DontRun rather than Don't::Run has sold its soul and should probably start with Com::ReallyBigCorporation::Enterprise:: Then I'll duck (low) and I will run. Yeah, but in Perl 5 the ' has been superseded with :: so you need to use Test::Include::Don::tRun ;-)
Module naming - Test::Import::DontRun
Hi, I have a module that attempts to import scripts/modules without executing anything in top level scope, so that test scripts can import their functions/methods and test them. Is Test::Import::DontRun a sufficiently descriptive name? I also thought about Test::DontRun, and Test::DontExecute, but prefer Test::Import::DontRun as more descriptive. thanks, Charles.
