You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by William McKee <wi...@knowmad.com> on 2004/04/08 16:23:54 UTC
t_cmp oddities
Hi Stas,
I've encountered an anomaly in t_cmp which seems to run against the
documented behavior. The easiest way to describe it is with an example.
In my response handler, I have the following two tests:
ok t_cmp (
undef,
&get_undef,
"Retrieve undef from subroutine"
);
my $rv = &get_undef;
ok t_cmp (
undef,
$rv,
"Retrieve undef from subroutine - use variable for comparison"
);
sub get_undef {
return;
}
Here's the output:
# expected: undef
# received: Retrieve undef from subroutine
not ok 1
# testing : Retrieve undef from subroutine - use variable for comparison
# expected: undef
# received: undef
ok 2
As you can see, the first version tries to compare the description
instead of the undef value returned from the function. Do you see
similar behavior or have I hit another problem with my environment?
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: t_cmp oddities
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>whichever is fine with me. Though please explain where did you take that
>>standard from? I think most modules follow the followinig import
>>convention:
>>
>>- a word 'foo' usually means symbol and you'd expect to be able to use
>>it in a form of (*$@%&)foo.
>>
>>- a tag ':foo' means, import a group of tags.
>>
>>- a string '-foo' means, tell import to do something, i.e. a command.
>
>
> outside of our world and CGI.pm I've never seen the '-foo' syntax. that
> Exporter doesn't support it natively led me to believe that it was merely a
> convention used by only a few. but I'll accept that it is more standard
> than I think :)
>>And I prefer 'withtestmore', to imply: don't not import symbols
>>exportable by Test::More.
>
>
> ok, withtestmore it is. but if it's ok with you I still prefer the
> ':withtestmore' version - somehow the '-withtestmore' still looks strange to
> me, especially within quotes or qw and without an action (as in -compile =>
> qw(foo).
>>>but whatever. I'm just trying to make userspace easier.
>>
>>
>>geoff++
>
>
> so you're in favor, then? if you are, I figure I'll commit it and some
> docs, then hope some of the Test::More fans (hi David) can see if it makes
> life easier before the next release.
Yes, +1 to :withtestmore
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: t_cmp oddities
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> whichever is fine with me. Though please explain where did you take that
> standard from? I think most modules follow the followinig import
> convention:
>
> - a word 'foo' usually means symbol and you'd expect to be able to use
> it in a form of (*$@%&)foo.
>
> - a tag ':foo' means, import a group of tags.
>
> - a string '-foo' means, tell import to do something, i.e. a command.
outside of our world and CGI.pm I've never seen the '-foo' syntax. that
Exporter doesn't support it natively led me to believe that it was merely a
convention used by only a few. but I'll accept that it is more standard
than I think :)
> And I prefer 'withtestmore', to imply: don't not import symbols
> exportable by Test::More.
ok, withtestmore it is. but if it's ok with you I still prefer the
':withtestmore' version - somehow the '-withtestmore' still looks strange to
me, especially within quotes or qw and without an action (as in -compile =>
qw(foo).
>> but whatever. I'm just trying to make userspace easier.
>
>
> geoff++
so you're in favor, then? if you are, I figure I'll commit it and some
docs, then hope some of the Test::More fans (hi David) can see if it makes
life easier before the next release.
--Geoff
Re: t_cmp oddities
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>I understand that your patch proposes to introduce:
>>
>>use Apache::TestUtil qw(:testmore);
>>use Test::More;
>>
>>correct?
>
>
> Apache::Test, not TestUtil, but yes.
argh, right, which makes my second part of the answer mostly irrelevant since
I thought you were talking about TestUtil.
>>There are two things:
>>
>>1. :tesmore imports has nothing to do with Test::More, so that tag is
>>very confusing. How about fixing import() instead and use a special
>>optional first argument:
>>
>>use Apache::TestUtil '-withtestmore';
>>use Test::More;
>>
>>or similar?
>
>
> testmore, withtestmore, whatever you want to call it. as for the '-foo'
> versus 'foo' stuff one is more standard than the other but however you
> prefer is fine.
whichever is fine with me. Though please explain where did you take that
standard from? I think most modules follow the followinig import convention:
- a word 'foo' usually means symbol and you'd expect to be able to use it in a
form of (*$@%&)foo.
- a tag ':foo' means, import a group of tags.
- a string '-foo' means, tell import to do something, i.e. a command.
And I prefer 'withtestmore', to imply: don't not import symbols exportable by
Test::More.
>>2. Apache::TestUtil's ok, skip and plan aren't compatible with
>>Test::More's one, so I'm not sure what do you achieve with this patch.
>
>
> what you get is all of Apache::Test except ok, skip, and plan. those are
> the methods that get redefined warnings and cause problems when you try to
> mix the two modules (especially with fatal warnings). in particular
> Test::More requires you to use Test::More::plan() or else each of its
> methods (say, is_deeply()) complains about not having called Test::More::plan().
That makes sense.
>>IMHO, users wanting to only use Apache::TestUtil's certain functions
>>while using Test::More should simply import only those functions.
>>Problem solved.
>
>
> for the most part I (and others I have talked to) want to use just about all
> the methods from each: all the have_* functions from Apache::Test as well as
> the like() functions from Test::More. if you wanted that, you would need to
> hand-type 17 import methods from Apache::Test. this eliminates the need for
> that and allows for a more idiomatic usage. simply
>
> use Apache::TestUtil qw(:testmore);
> use Test::More;
>
> gives you everything from Apache::Test except those methods that collide
> with Test::More. you are then free to use Apache::TestUtil functions in
> your tests while keeping with Test::More's familar plan() and ok() interface.
See you are confused just as I do :0) It's Apache::Test, not Apache::TestUtil
that you are after. It was just a wrong thread to disscuss this, my head was
absorbed inside TestUtil.
> but whatever. I'm just trying to make userspace easier.
geoff++
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: t_cmp oddities
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> I understand that your patch proposes to introduce:
>
> use Apache::TestUtil qw(:testmore);
> use Test::More;
>
> correct?
Apache::Test, not TestUtil, but yes.
>
> There are two things:
>
> 1. :tesmore imports has nothing to do with Test::More, so that tag is
> very confusing. How about fixing import() instead and use a special
> optional first argument:
>
> use Apache::TestUtil '-withtestmore';
> use Test::More;
>
> or similar?
testmore, withtestmore, whatever you want to call it. as for the '-foo'
versus 'foo' stuff one is more standard than the other but however you
prefer is fine.
>
> 2. Apache::TestUtil's ok, skip and plan aren't compatible with
> Test::More's one, so I'm not sure what do you achieve with this patch.
what you get is all of Apache::Test except ok, skip, and plan. those are
the methods that get redefined warnings and cause problems when you try to
mix the two modules (especially with fatal warnings). in particular
Test::More requires you to use Test::More::plan() or else each of its
methods (say, is_deeply()) complains about not having called Test::More::plan().
>
> IMHO, users wanting to only use Apache::TestUtil's certain functions
> while using Test::More should simply import only those functions.
> Problem solved.
for the most part I (and others I have talked to) want to use just about all
the methods from each: all the have_* functions from Apache::Test as well as
the like() functions from Test::More. if you wanted that, you would need to
hand-type 17 import methods from Apache::Test. this eliminates the need for
that and allows for a more idiomatic usage. simply
use Apache::TestUtil qw(:testmore);
use Test::More;
gives you everything from Apache::Test except those methods that collide
with Test::More. you are then free to use Apache::TestUtil functions in
your tests while keeping with Test::More's familar plan() and ok() interface.
but whatever. I'm just trying to make userspace easier.
--Geoff
Re: t_cmp oddities
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>The main problem is the dependency which we we don't want to create in
>>Apache-Test.
>
>
> yes, I agree. but I think that something like this would be great, as it
> would keep users from needing to jump through a bunch of hoops just to
> prevent redefined warnings.
I understand that your patch proposes to introduce:
use Apache::TestUtil qw(:testmore);
use Test::More;
correct?
There are two things:
1. :tesmore imports has nothing to do with Test::More, so that tag is very
confusing. How about fixing import() instead and use a special optional first
argument:
use Apache::TestUtil '-withtestmore';
use Test::More;
or similar?
2. Apache::TestUtil's ok, skip and plan aren't compatible with Test::More's
one, so I'm not sure what do you achieve with this patch.
IMHO, users wanting to only use Apache::TestUtil's certain functions while
using Test::More should simply import only those functions. Problem solved.
> Index: lib/Apache/Test.pm
> ===================================================================
> RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/Test.pm,v
> retrieving revision 1.77
> diff -u -r1.77 Test.pm
> --- lib/Apache/Test.pm 9 Mar 2004 01:21:32 -0000 1.77
> +++ lib/Apache/Test.pm 12 Apr 2004 19:48:06 -0000
> @@ -22,7 +22,7 @@
> use Config;
> use Apache::TestConfig ();
>
> -use vars qw(@ISA @EXPORT $VERSION %SubTests @SkipReasons);
> +use vars qw(@ISA @EXPORT %EXPORT_TAGS $VERSION %SubTests @SkipReasons);
>
> @ISA = qw(Exporter);
> @EXPORT = qw(ok skip sok plan have have_lwp have_http11
> @@ -30,6 +30,12 @@
> have_min_apache_version have_apache_version have_perl
> have_min_perl_version have_min_module_version
> have_threads under_construction have_apache_mpm);
> +
> +# everything but ok(), skip(), and plan() - Test::More provides these
> +my @test_more_exports = grep { ! /^(ok|skip|plan)$/ } @EXPORT;
> +
> +%EXPORT_TAGS = (testmore => \@test_more_exports);
> +
> $VERSION = '1.10';
>
> %SubTests = ();
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: t_cmp oddities
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> The main problem is the dependency which we we don't want to create in
> Apache-Test.
yes, I agree. but I think that something like this would be great, as it
would keep users from needing to jump through a bunch of hoops just to
prevent redefined warnings.
--Geoff
Re: t_cmp oddities
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>I like that idea of adopting all of T::M. However, does T::M have a
>>comparable function to t_cmp that gives the expected and received
>>values? I *really* like the verbose output that t_cmp gives!
>
>
> is() is similar in many ways to t_cmp() except it doesn't support array
> comparisons, regular expressions, and some of the other things t_cmp() does.
> but Test::More has stuff like like(), is_deeply(), and unlike() (which has
> no Apache-Test equivalent). Test::More is a bit different in that you only
> get the expected/received messages when things fail IIRC.
>
> that said, integrating Apache-Test with Test::More is a bit difficult - you
> get all kinds of redefined sub warnings because both Apache::Test and
> Test::More export plan() and ok() into the test's namespace. I originally
> thought that I could create a simple Apache::TestMore class that merely
> exported all the right stuff, but it ends up being a bit more complex than
> that. so, it's on my todo list at the moment but I just haven't had the
> time. if someone beats me to it, great :)
The main problem is the dependency which we we don't want to create in
Apache-Test. Though nothing prevents from you, William, to use T::M in your
test suite. Apache::TestUtil simply is a smaller T::M-like library, but you
don't have to use it.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: t_cmp oddities
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> I like that idea of adopting all of T::M. However, does T::M have a
> comparable function to t_cmp that gives the expected and received
> values? I *really* like the verbose output that t_cmp gives!
is() is similar in many ways to t_cmp() except it doesn't support array
comparisons, regular expressions, and some of the other things t_cmp() does.
but Test::More has stuff like like(), is_deeply(), and unlike() (which has
no Apache-Test equivalent). Test::More is a bit different in that you only
get the expected/received messages when things fail IIRC.
that said, integrating Apache-Test with Test::More is a bit difficult - you
get all kinds of redefined sub warnings because both Apache::Test and
Test::More export plan() and ok() into the test's namespace. I originally
thought that I could create a simple Apache::TestMore class that merely
exported all the right stuff, but it ends up being a bit more complex than
that. so, it's on my todo list at the moment but I just haven't had the
time. if someone beats me to it, great :)
--Geoff
Re: t_cmp oddities
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
>>Also William can you check what Test::More does to deal with this problem?
>>Eventually we may drop t_cmp completely and move into Test::More, whose API
>>is much reacher and you better use it from the very beginning instead of
>>Apache::TestUtil, if you can afford requiring Test::More.
>
>
> All tests in the following script pass:
>
> ---------------------------------
> use Test::More tests => 2;
>
> # Test scripts for Stas
> is (
> undef,
> &get_undef,
> "Retrieve undef from subroutine"
> );
> sub get_undef {
> return;
> }
> ---------------------------------
Thanks William,
I've checked the implementation in Test/More.pm and fixed t_cmp() accordingly:
-sub t_cmp {
+sub t_cmp ($$;$) {
the workarounds are no longer needed with the current cvs version of A-T.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: t_cmp oddities
Posted by William McKee <wi...@knowmad.com>.
On Thu, Apr 08, 2004 at 10:56:06AM -0700, Stas Bekman wrote:
> Yes, I'm aware of this problem too. I sometimes use a different workaround.
> Using Geoff's one liner:
OK, I'll use this method.
> Also William can you check what Test::More does to deal with this problem?
> Eventually we may drop t_cmp completely and move into Test::More, whose API
> is much reacher and you better use it from the very beginning instead of
> Apache::TestUtil, if you can afford requiring Test::More.
All tests in the following script pass:
---------------------------------
use Test::More tests => 2;
# Test scripts for Stas
is (
undef,
&get_undef,
"Retrieve undef from subroutine"
);
my $rv = &get_undef;
is (
undef,
$rv,
"Retrieve undef from subroutine - use variable for
comparison"
);
sub get_undef {
return;
}
---------------------------------
I like that idea of adopting all of T::M. However, does T::M have a
comparable function to t_cmp that gives the expected and received
values? I *really* like the verbose output that t_cmp gives!
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: t_cmp oddities
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Thu, Apr 08, 2004 at 10:57:58AM -0700, Stas Bekman wrote:
>
>>and we ought to document this... hint, hint :)
>
>
> I have attached a diff against v1.09 of the TestUtil.pm file. I'm not
> sure if my explanation is entirely accurate. Please review and let me
> know.
>
>
> Thanks,
> William
>
>
>
> ------------------------------------------------------------------------
>
> --- TestUtil.pm.orig 2004-04-09 11:58:59.000000000 -0400
> +++ TestUtil.pm 2004-04-09 12:01:16.000000000 -0400
> @@ -424,6 +424,11 @@
>
> This function is exported by default.
>
> +When comparing undef values, you must force the received value into an lvalue.
> +You can do this with the following example:
> +
> + t_cmp(undef, scalar foo(), "compare undef return value from foo()")
> +
Thanks William, I've committed this included the other solution as well.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: t_cmp oddities
Posted by William McKee <wi...@knowmad.com>.
On Thu, Apr 08, 2004 at 10:57:58AM -0700, Stas Bekman wrote:
> and we ought to document this... hint, hint :)
I have attached a diff against v1.09 of the TestUtil.pm file. I'm not
sure if my explanation is entirely accurate. Please review and let me
know.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: t_cmp oddities
Posted by Stas Bekman <st...@stason.org>.
and we ought to document this... hint, hint :)
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: test-perl-framework test fails for apache 2.0
Posted by Stas Bekman <st...@stason.org>.
Abhishek Khandelwal wrote:
> I have that installed and version is 5.76
> I guess its part of module libwww-perl-5.76
Yes, it is.
> Any other idea what the problem might be?
I don't have mod_ssl built, so all ssl tests are skipped for me. Ask at the
httpd-dev list?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: test-perl-framework test fails for apache 2.0
Posted by Abhishek Khandelwal <ak...@spikesource.com>.
I have that installed and version is 5.76
I guess its part of module libwww-perl-5.76
Any other idea what the problem might be?
On Thu, 2004-04-08 at 18:16, Stas Bekman wrote:
> Abhishek Khandelwal wrote:
> > I am not sure about it?
> > How do I check whether its installed or not?
>
> perl -MLWP -le 'print LWP->VERSION'
>
> > In case it is not installed how do I install?
> > would be from CPAN.. install LWP?
>
> yup
Re: test-perl-framework test fails for apache 2.0
Posted by Stas Bekman <st...@stason.org>.
Abhishek Khandelwal wrote:
> I am not sure about it?
> How do I check whether its installed or not?
perl -MLWP -le 'print LWP->VERSION'
> In case it is not installed how do I install?
> would be from CPAN.. install LWP?
yup
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: test-perl-framework test fails for apache 2.0
Posted by Abhishek Khandelwal <ak...@spikesource.com>.
I am not sure about it?
How do I check whether its installed or not?
In case it is not installed how do I install?
would be from CPAN.. install LWP?
Thanks
On Thu, 2004-04-08 at 17:56, Stas Bekman wrote:
> Abhishek Khandelwal wrote:
> > Hi Stas,
> >
> > I installed apache httpd and the usual Apache::TestBundle.
> > Finally when I run the tests, I get this error in ssl/http.t module
> >
> > Anyone has idea about what might be missing in the configuration or is
> > it a bug in apache 2.0?
> >
> > This is the error I get::
> >
> > -------------------------------------------------------------------
> >
> > ssl/http.................response had protocol HTTP/0.9 (headers not
> > sent?) at ssl/http.t line 27
> > dubious
> > Test returned status 255 (wstat 65280, 0xff00)
> > Scalar found where operator expected at (eval 170) line 1, near "'int'
> > $__val"
> > DIED. FAILED tests 1-2
> > Failed 2/2 tests, 0.00% okay
> > (Missing operator before $__val?)
> >
> > ----------------------------------------------------------------------
>
> May be you don't have LWP installed?
>
Re: test-perl-framework test fails for apache 2.0
Posted by Stas Bekman <st...@stason.org>.
Abhishek Khandelwal wrote:
> Hi Stas,
>
> I installed apache httpd and the usual Apache::TestBundle.
> Finally when I run the tests, I get this error in ssl/http.t module
>
> Anyone has idea about what might be missing in the configuration or is
> it a bug in apache 2.0?
>
> This is the error I get::
>
> -------------------------------------------------------------------
>
> ssl/http.................response had protocol HTTP/0.9 (headers not
> sent?) at ssl/http.t line 27
> dubious
> Test returned status 255 (wstat 65280, 0xff00)
> Scalar found where operator expected at (eval 170) line 1, near "'int'
> $__val"
> DIED. FAILED tests 1-2
> Failed 2/2 tests, 0.00% okay
> (Missing operator before $__val?)
>
> ----------------------------------------------------------------------
May be you don't have LWP installed?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
test-perl-framework test fails for apache 2.0
Posted by Abhishek Khandelwal <ak...@spikesource.com>.
Hi Stas,
I installed apache httpd and the usual Apache::TestBundle.
Finally when I run the tests, I get this error in ssl/http.t module
Anyone has idea about what might be missing in the configuration or is
it a bug in apache 2.0?
This is the error I get::
-------------------------------------------------------------------
ssl/http.................response had protocol HTTP/0.9 (headers not
sent?) at ssl/http.t line 27
dubious
Test returned status 255 (wstat 65280, 0xff00)
Scalar found where operator expected at (eval 170) line 1, near "'int'
$__val"
DIED. FAILED tests 1-2
Failed 2/2 tests, 0.00% okay
(Missing operator before $__val?)
----------------------------------------------------------------------
Please help
Abhishek
Re: t_cmp oddities
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Geoffrey Young wrote:
>
>>> ok t_cmp (
>>> undef,
>>> &get_undef,
>>> "Retrieve undef from subroutine"
>>> );
>>
>>
>>> # expected: undef
>>> # received: Retrieve undef from subroutine
>>> not ok 1
>>
>>
>>get_undef is slurping up the text as an argument. call it as get_undef()
>>instead (nobody really uses the & calling format anymore anyway :)
>
>
> oh, wait, that's not it. anyway, I've seen this myself before which is why
> I was quick to (wrongly) answer :) personally, I usually just
>
> my $val = get_undef;
>
> t_cmp(1, $val, "text");
>
> the problem seems to be with return
>
> $ perl -MApache::TestUtil -e 't_cmp(1,foo(),"text"); sub foo { return }'
> # expected: 1
> # received: text
>
> $ perl -MApache::TestUtil -e 't_cmp(1,foo(),"text"); sub foo { return undef }'
> # testing : text
> # expected: 1
> # received: undef
>
> and 'return undef' is considered bad form, since it doesn't do the right
> thing in a list context, so most people won't do it. but it's the list
> context that's tripping us up, as @_ that t_cmp() receives is now only 2
> arguments wide:
>
> $ perl -e '@a = (1, foo(), "text"); print scalar @a; sub foo { return }'
> 2
>
> I don't think there is anything we can do about it, so just use the
> workaround above.
Yes, I'm aware of this problem too. I sometimes use a different workaround.
Using Geoff's one liner:
perl -MApache::TestUtil -e 't_cmp(1,scalar(foo()),"text"); sub foo { return }'
perl -le '@a = (1, scalar foo(), "text"); print scalar @a; sub foo { return }'
3
Also William can you check what Test::More does to deal with this problem?
Eventually we may drop t_cmp completely and move into Test::More, whose API is
much reacher and you better use it from the very beginning instead of
Apache::TestUtil, if you can afford requiring Test::More.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: t_cmp oddities
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Geoffrey Young wrote:
>> ok t_cmp (
>> undef,
>> &get_undef,
>> "Retrieve undef from subroutine"
>> );
>
>
>> # expected: undef
>> # received: Retrieve undef from subroutine
>> not ok 1
>
>
> get_undef is slurping up the text as an argument. call it as get_undef()
> instead (nobody really uses the & calling format anymore anyway :)
oh, wait, that's not it. anyway, I've seen this myself before which is why
I was quick to (wrongly) answer :) personally, I usually just
my $val = get_undef;
t_cmp(1, $val, "text");
the problem seems to be with return
$ perl -MApache::TestUtil -e 't_cmp(1,foo(),"text"); sub foo { return }'
# expected: 1
# received: text
$ perl -MApache::TestUtil -e 't_cmp(1,foo(),"text"); sub foo { return undef }'
# testing : text
# expected: 1
# received: undef
and 'return undef' is considered bad form, since it doesn't do the right
thing in a list context, so most people won't do it. but it's the list
context that's tripping us up, as @_ that t_cmp() receives is now only 2
arguments wide:
$ perl -e '@a = (1, foo(), "text"); print scalar @a; sub foo { return }'
2
I don't think there is anything we can do about it, so just use the
workaround above.
--Geoff
Re: t_cmp oddities
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> ok t_cmp (
> undef,
> &get_undef,
> "Retrieve undef from subroutine"
> );
> # expected: undef
> # received: Retrieve undef from subroutine
> not ok 1
get_undef is slurping up the text as an argument. call it as get_undef()
instead (nobody really uses the & calling format anymore anyway :)
--Geoff