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 isnt_code) );
> is_code sub { 1 }, sub { 1 },
> 'Basic subs should match';
is_code() is a sucky name as it more says to me "is this code" not "is X
routine the same as Y routine". You know this, but I thought I'd kick off
the discussion here.
Alternatives:
eq_code()
same_code()
> isnt_code
> sub { print for 1 .. 4 },
> sub { for (1 .. 4) { print } },
> 'Subtle lexical issues should cause the match to fail (darn it)';
>
> The last example really bugs me. I'd like for that to work, but it
> doesn't. Also, variables with different names will fail, even if the
> code is functionally identical. I'm currently using B::Deparse to
> handle this, but in the long run, I'd really prefer to be able to use
> PPI::Normal and fail back to B::Deparse.
>
> Right now, this test module is not as useful as I would like due to
> caveats listed above. Suggestions welcome.
Enumerate the caveats in the docs and leave those cases as undefined. You
can also manage expectations by saying that you're testing for functional
equivalency, not code equivalency. So this:
is_code sub { my $foo = 2; return $foo + 2 },
sub { my $bar = 2; return $bar + 2 };
would eventually pass... even if it currently doesn't.
Also, what do the failure diagnostics look like?
--
Michael G Schwern schwern@xxxxxxxxx http://www.pobox.com/~schwern
Life is like a sewer - what you get out of it depends on what you put into it.
- Tom Lehrer
|
