DrHyde / perl-modules-Test-Differences

Test::Differences

Home Page:http://search.cpan.org/dist/Test-Differences/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Odd failures with eq_or_diff starting on 5.38.0

jjatria opened this issue · comments

False negatives started coming up with the release of 5.38.0. Noticed this while exploring the failures in Google::ProtocolBuffers::Dynamic, which uses this library for its test suite.

In that case, the failures start on or around 5.37.2, in case that helps narrow this down.

I think this test should reproduce the failure:

$ perlbrew use perl-5.36.1
$ perl -MTest::More -MTest::Differences -E 'eq_or_diff( !!1, 1 ); done_testing'
ok 1
1..1
$ perlbrew use perl-5.38.0
$ perl -MTest::More -MTest::Differences -E 'eq_or_diff( !!1, 1 ); done_testing'
not ok 1
#   Failed test at -e line 1.
# +---+-----+----------+
# | Ln|Got  |Expected  |
# +---+-----+----------+
# *  1|!!1  |1         *
# +---+-----+----------+
1..1
# Looks like you failed 1 test of 1.

Historically, true and false (whether resulting from logical-not ! or from equality checks like ==) were represented as numeric 1 for true and the empty string '' for false. In perl 5.36.0 they became real Boolean values which for backward compatibility also have their old numeric/string values. In 5.38 (and in dev releases from 5.37.2 onwards) Data::Dumper belatedly learned about this, and so Test::Differences (which uses Data::Dumper under the bonnet) can also tell the difference.

This isn't a bug, although I do sympathise and it is a bit annoying. I will make it clear in the documentation.

Doco update is in 24fa476

Thanks for the clarification. FWIW, using builtin::true and builtin::false as the check works:

$ perlbrew use perl-5.36.1
$ perl -Mexperimental=builtin -Mbuiltin=true -MTest::More -MTest::Differences -E 'eq_or_diff( !!1, true ); done_testing'
ok 1
1..1
$ perlbrew use perl-5.38.0
$ perl -Mexperimental=builtin -Mbuiltin=true -MTest::More -MTest::Differences -E 'eq_or_diff( !!1, true ); done_testing'
ok 1
1..1

If using "experimental" features is not acceptable, this is also a suitable workaround:

use constant {
    true  => !!1,
    false => !!0,
};