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
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.
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 :-)
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.