Open demerphq opened 1 year ago
Is it important that the lock_keys
test operate on %ENV
? Could it pick a hash with fewer consequences?
Is it important that the
lock_keys
test operate on%ENV
?
Yes it is important that we test that lock_keys can operate on %ENV. It is a magic hash, and people might want to lock it.
Could it pick a hash with fewer consequences?
Most of our tests are against "normal hashes", but that doesn't tell us that the locking mechanism works on a magic hash like %ENV.
Module Hash::Util aka ext/Hash-Util/lib/Hash/Util.pm Test::More aka cpan/Test-Simple/lib/Test2/Formatter/TAP.pm (I have filed https://github.com/Test-More/test-more/issues/907 for this part of the bug)
Description ext/Hash-Util/t/Util.t contains the following code:
If this test fails then it will break Test::More (it says Test::Builder, but i think that is wrong these days) with a message like this:
It is debatable whether this is a failure in Test::More or Hash::Util. Arguably both. I noticed this while working on https://github.com/Perl/perl5/pull/20928 and i solved it by replacing the code with the following:
However this includes a change to the error message from locked hashes, so it can't be applied directly.
I will also file a bug with Test::More as this one is a bit debatable. Is expecting Test::More to deal with a locked %ENV reasonable? Should Test::More copy %ENV super early before any code can lock it? Should Hash::Util be changed as I did in my PR?
Steps to Reproduce
Expected behavior The test failing shouldn't completely break Test::More. :-)
Perl configuration This isnt really relevant, but