http://qs1969.pair.com?node_id=702002

Ovid has asked for the wisdom of the Perl Monks concerning the following question:

There's a nasty bug in the latest development version of Test::Differences. By applying a patch which allows this to pass (it currently won't):

  eq_or_diff { foo => 1 }, { foo => '1' };

It also allows this to pass:

  eq_or_diff [ { foo => 1 } ], { foo => '1' };

Ow, ow, ow. This is terrible. Fortunately, that's what development versions are for.

I'm thinking about rewriting Test::Differences to use &Test::More::is_deeply for the test and only diff if there are differences. Currently it uses Data::Dumper or its own internal flattening and and compares the string outputs.

There are two side-effects I can think of. First, the string/numeric value comparison will work correctly. Second, the 'Array of HashRef' diff output will change dramatically. There's an internal hack which assumes an AoH is a table (likely pulled from DBI, I assume), and this:

eq_or_diff [ { name => 'Bob', id => 1 } ], [ { name => 'Bob', id => 2 } ], 'aoh';

Generates this:

# Failed test 'aoh' # at eq_or_diff.t line 13. # +----+---------+----------+ # | Elt|Got |Expected | # +----+---------+----------+ # | 0|id,name |id,name | # * 1|1,Bob |2,Bob * # +----+---------+----------+

I find this much harder to read, but others may appreciate the hash keys being pulled out as headers.

Does anyone object to me breaking this? Are there any problems that I haven't thought of? (There usually are).

Replies are listed 'Best First'.
Re: Breaking Test::Differences
by amarquis (Curate) on Aug 04, 2008 at 13:26 UTC

    "I find this much harder to read, ..."

    I agree, but in my experience I'm never trying to wrap my head around the whole data structure by looking at the diff. Earlier tests weed out those 'macro' problems, and by the time I get to the tests that use eq_or_diff I'm looking for tiny things. So, for what it is worth, in my case the changed format wouldn't bother me one bit.

      Likewise, I use eq_or_diff in "prove -v" context (otherwise good old is_deeply).
Re: Breaking Test::Differences
by Anonymous Monk on Aug 04, 2008 at 08:49 UTC
    Does anyone object to me breaking this? Are there any problems that I haven't thought of? (There usually are).

    You appear to be fond of breaking things for no reason other than you found something chipped. I suggest you ask those who use Test::Differences directly.

      It's so safe to be anonymous, isn't it? It means you get be wrong and not have anyone know who you are. At least when I'm wrong, I'm willing to put my name on it.

      It's not chipped, it's broken. Has been a for a long time and there was a patch sitting in the queue for this problem (a problem that has bitten me and many other individuals). My only hope is to fix the broken equality test and the only change is to clean up the diagnostics, something which isn't machine-readable anyway.

        I am not the person you replied to, but I will respond to your attack on anonymity.

        I registered on perlmonks.org once. I can’t remember my password. I can never be bothered to go through the “e-mail me my password” dance just to post a comment. I wish perlmonks.org supported openid.

        I never say in the text of a comment who I am, because anyone could claim to be me.

        It's not chipped, it's broken.

        If its that clear cut, why do you need to ask for objections?

        I didn't see the rudeness (no, I'm not who you replied to either). However, I will choose to be anonymous this time so I can minimize how much I have to deal with your immaturity at dealing with criticism.

        "chipped" is a form of "broken". I don't know anything about what personal "fondness"es you might or might not have, but I'll try to make part of the original point clearer to you, This looks very much like shattering something because it was chipped.

        And a patch that fixes comparison between numbers and numeric strings but breaks comparison of nesting levels sounds more like replacing some small fundamental cog with a side-effect of fixing a particular bug. It seems unlikely that it wouldn't be possible to more directly fix the bug and not introduce such a different bug.

        If you feel the need to fundamentally change the whole heart of the module, you should probably start by making the "new world order" version an option (and an opt-in one at that).