Open PootieT opened 1 year ago
@mgree / @mhyee any opinions on this one?
Probably better to generate custom equality checking code when the expected output is ""
rather than munging the test case translation itself.
What type of error is this:
Here is an argument for the latter: this is what the Test::Deep
library does. If it's a reasonable testing library, we should just use its notions of equality.
I think the comparison should be relaxed. It looks like "numeric false" (0
or "0"
) and "string false" (""
) aren't equal but should be.
A scalar value is interpreted as FALSE in the Boolean sense if it is undefined, the null string or the number 0 (or its string equivalent, "0"), and TRUE if it is anything else.
https://perldoc.perl.org/perldata#Scalar-values
Some answers on StackOverflow recommended !!0
for false (but others discourage it for being obscure symbols), but I tried it and Test::Deep
considers it different from 0
(but equal to ""
).
It seems like Perl's ==
does the right thing:
$ perl -e 'print((0== "") . "\n"); print(!!0 == "") ."\n"); print((1 == "") . "\n")'
1
1
Maybe we can say $got == $expected || eq_deeply($got, $expected)
?
I have a feeling that this may have been debated but testing boolean values in Perl may need improvement
Example:
HumanEval_92_any_int
It seems like at the moment, when the program is expected to output
False
, it is being compared against""
witheq_deeply
. Many generations in perl, though, return 0/1. But the following comparison between0
and""
seem to evaluate to FalseMaybe, one solution is to directly use the output of these functions as the condition for the
if
statement for that unit test (only when output is expected to be boolean)