# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46889]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46889 >
In t/perl/Parrot_Test.t there is the todo item:
# XXX Shouldn't this be in an END bloc
--- demerphq <[EMAIL PROTECTED]> wrote:
> One idea might be to try using Data::Dump::Streamer for your tests.
> It
> will serialize the lexical context that the subroutine was compiled
> with (including bound anonymous subroutines and their lexical
> context).
>
> A small hack (that i would be ha
ng them. To this end, I've started writing Test::Code.
> Here's the start of my test suite (more or less):
>
> BEGIN { use_ok 'Test::Code' or die }
>
> ok defined *::is_code{CODE},
> '&is_code should be exported to our namespace';
> i
* David Golden <[EMAIL PROTECTED]> [2005-08-12T09:10:21]
> Won't "&is_code" get called that way? Should this be:
>
> ok defined \&is_code;
No. C will do the right thing, here. Taking a reference to an
undefined sub, however, will always return a defined value: a coderef
that, when called,
Ivan Tubert-Brohman wrote:
Isn't
ok defined *::is_code{CODE};
just a convoluted way of saying
ok defined &is_code;
Won't "&is_code" get called that way? Should this be:
ok defined \&is_code;
David Golden
Ovid wrote:
X-Posted to Perlmonks (http://perlmonks.org/index.pl?node_id=483100)
I frequently write code that generates anonymous functions on the fly.
However, I often want to verify that these functions are correct
without executing them. To this end, I've started writing Test:
[EMAIL PROTECTED] wrote:
You may wish to look at Test::Inline and Test::Class which are different
approaches to putting your tests near your code.
Test::Inline looks like what I'm thinking - thanx
Also __TEST__ is not legal Perl which gets into source filters and then the
burning and itc
--- Ivan Tubert-Brohman <[EMAIL PROTECTED]> wrote:
> Isn't
>
>ok defined *::is_code{CODE};
>
> just a convoluted way of saying
>
>ok defined &is_code;
Er, yes. It is. That's just a really bad habit on my part. I do a
fair amount of typeglob diddling, so that tends to stick in my min
On Fri, Aug 12, 2005 at 10:28:36AM +1000, [EMAIL PROTECTED] wrote:
> I'm thinking that the code, tests, data and pod are all there in the pm
> file - that seems on the surface a good thing. Does this seem like a
> reasonable idea ?
>
> Against it is the significant inertia the current .t regime
Michael G Schwern wrote:
On Thu, Aug 11, 2005 at 02:49:57PM -0700, Ovid wrote:
BEGIN { use_ok 'Test::Code' or die }
ok defined *::is_code{CODE},
'&is_code should be exported to our namespace';
I usually do this with can_ok()
can_ok( __PACKAGE
--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > ok defined *::is_code{CODE},
> > '&is_code should be exported to our namespace';
>
> I usually do this with can_ok()
>
> can_ok( __PACKAGE__, qw(is_code isnt_code) );
I specifically avoid that with methods because &can_ok provides
[EMAIL PROTECTED] wrote:
I usually do this with can_ok()
can_ok( __PACKAGE__, qw(is_code isnt_code) );
Initially i thought "Would that work ? Isnt __PACKAGE__ equal to main::
in a t file ?" then I realised we're testing that the use_ok is
exporting these to our namespace, which
On Thu, Aug 11, 2005 at 02:49:57PM -0700, Ovid wrote:
> BEGIN { use_ok 'Test::Code' or die }
>
> ok defined *::is_code{CODE},
> '&is_code should be exported to our namespace';
I usually do this with can_ok()
can_ok( __PACKAGE__, qw(is_code
X-Posted to Perlmonks (http://perlmonks.org/index.pl?node_id=483100)
I frequently write code that generates anonymous functions on the fly.
However, I often want to verify that these functions are correct
without executing them. To this end, I've started writing Test::Code.
Here's th
14 matches
Mail list logo
