RT:
:Create returns an array, so when evaluated in
a scalar context it is always true. Correct?
If so, isn’t this testing code from Tickets_Overlay_SQL flawed?
ok( $t->Create(Queue => ‘General’, Subject => $string), “Ticket Created”);
RT:
:Create returns an array, so when evaluated in
a scalar context it is always true. Correct?If so, isn’t this testing code from Tickets_Overlay_SQL flawed?
ok( $t->Create(Queue => ‘General’, Subject => $string), “Ticket Created”);
Yep. that looks flawed.
RT:
a scalar context it is always true. Correct?
in a scalar context an array evaluates to the number of elements in it,
so it is not always “true”.
Vivek Khera, Ph.D.
+1-301-869-4449 x806
RT:
a scalar context it is always true. Correct?in a scalar context an array evaluates to the number of elements in it,
so it is not always “true”.Vivek Khera, Ph.D.
+1-301-869-4449 x806
But since that method always returns 3 elements it will always
be true in this case.
RT:
a scalar context it is always true. Correct?If so, isn’t this testing code from Tickets_Overlay_SQL flawed?
ok( $t->Create(Queue => ‘General’, Subject => $string), “Ticket Created”);
Yep. that looks flawed.
That type of problem looks to be somewhat common in the RT testing
code. It has bugged me a little why RT doesn’t use wantarray
or put error messages in global vaiables, so that it is easier
to call Create and the like in scalar context.
That type of problem looks to be somewhat common in the RT testing
code.
Really? I’ve not seen it much at all. patches are appreciated.
Most of the place, the idiom is:
($id,$msg) = RT::Foo->Bar();
ok($id,$msg);
It has bugged me a little why RT doesn’t use wantarray
or put error messages in global vaiables, so that it is easier
to call Create and the like in scalar context.
Have a look at Class::ReturnValue, which is the library I wrote to
enable just such functionality. But the time to retrofit it into code
has been scarce.
That type of problem looks to be somewhat common in the RT testing
code.Really? I’ve not seen it much at all. patches are appreciated.
Most of the place, the idiom is:
Well, I said somewhat. Not meant as a blanket criticism of RT’s
code. And yes, I will try to send some patches.
($id,$msg) = RT::Foo->Bar();
ok($id,$msg);It has bugged me a little why RT doesn’t use wantarray
or put error messages in global vaiables, so that it is easier
to call Create and the like in scalar context.Have a look at Class::ReturnValue, which is the library I wrote to
enable just such functionality. But the time to retrofit it into code
has been scarce.
Cool, I’ll take a look.
Todd Chapman wrote:
Matthew Draper wrote:
Todd Chapman wrote:
RT:
a scalar context it is always true. Correct?If so, isn’t this testing code from Tickets_Overlay_SQL flawed?
ok( $t->Create(Queue => ‘General’, Subject => $string), “Ticket Created”);
Flawed in so much as it doesn’t do what it looks like it does,
certainly. It does actually do the right test, though.Look closer… that looks suspiciously like a list context to me.
I don’t think so. ok() compares to scalars.
Yes, but before it does so, Perl evaluates the list of arguments to pass
it.
(Sorry about hitting the wrong reply button before.)
signature.asc (254 Bytes)
Hi,
I want to calculate “resolution time” for a ticket considerin business
hours (do not count the time out of business hours but only the "active"
time). I found on CPAN one old module from Jesse, but that’s all.
Before starting to hack and fetch my old geometry books - did anyone
solve this already?
I need to consider public holidays, Weekends and opening hours…ideally
it would be based on a Vcard / ical file…so we could change the dates
online…or just add a calendar to rt (;-)).
Thanks
Alex
Todd Chapman wrote:
Matthew Draper wrote:
Todd Chapman wrote:
RT:
a scalar context it is always true. Correct?If so, isn’t this testing code from Tickets_Overlay_SQL flawed?
ok( $t->Create(Queue => ‘General’, Subject => $string), “Ticket Created”);
Flawed in so much as it doesn’t do what it looks like it does,
certainly. It does actually do the right test, though.Look closer… that looks suspiciously like a list context to me.
I don’t think so. ok() compares to scalars.
Yes, but before it does so, Perl evaluates the list of arguments to pass
it.(Sorry about hitting the wrong reply button before.)
I don’t get it. Are you saying that there is no bug in the code above?
There is a bug, because the test will always pass, even if Queue is
mis-spelled.
ok( $t->Create(Queue => ‘General’, Subject => $string), “Ticket Created”);
I don’t get it. Are you saying that there is no bug in the code above?
There is a bug, because the test will always pass, even if Queue is
mis-spelled.
$ perl -MTest::More=no_plan -e’sub foo { (0,0,“Text”) ; } ok( foo(),
“Bar” )’
ok 1 - Bar
1…1
I’m pretty sure Todd has a point here.
$ perl -le ‘$x= (10,20,30); print $x’
30
(A list value in scalar context evaluates to the last element.)
Here’s the snippet from perldata:
If you evaluate an array in scalar context, it returns the length
of the array. (Note that this is not true of lists, which return the
lastvalue, like the C comma operator, nor of built-in functions, which
return whatever they feel like returning.)
There are several examples of ok( $x->Create( … ) ) in Ticket_Overlay.pm
-R
Robert wrote:
$ perl -MTest::More=no_plan -e’sub foo { (0,0,“Text”) ; } ok( foo(),
“Bar” )’
ok 1 - Bar
1…1I’m pretty sure Todd has a point here.
I stand corrected; I missed the prototype on Test::More::ok.
signature.asc (254 Bytes)