TransitivityFieldCheck is broken

[GoogleCodeExporter]

As discussed in [1], the TransitivityFieldCheck is broken.

Consider the attached test. Its equals method is not transitive, but according 
to the method described on my blog, it should still pass, because: "As I 
understand it, in each of the four cases you have that A1 shares 3 fields with 
B1, B1 shares 1 with B2 and A1 shares none with B2. So with my equals you 
should have A1==B1 && B1!=B2 && A1!=B2 in each case. Which means it is 
"transitive", right?"

Instead, it fails on transitivity. Which is what we want, but not what we 
expect.

It turns out that the object is not properly reset to its original value after 
each iteration. That means that the first time around, we get the following 
objects:

    A1 = i=1, j=1, k=1, l=1
    B1 = i=2, j=1, k=1, l=1
    B2 = i=2, j=2, k=2, l=2

But the second time around, they're like this:

    A1 = i=1, j=1, k=1, l=1
    B1 = i=2, j=2, k=1, l=1
    B2 = i=2, j=2, k=2, l=2

Obviously, the i field in B1 should be 1, not 2, if the implementation had 
followed the method described on my blog.

I think this should be fixed (and it should be easy to do so), but the downside 
is that the attached class wouldn't fail anymore :). I'll have to consider 
whether to add an extra check for this kind of class, or to let it be: one 
would have to be pretty evil to consider this in the first place, and EV's 
purpose is not to catch all thinkable kinds of evil equals methods; it should 
only (and at least) catch the plausibly wrong ones.



[1] http://www.jqno.nl/post/2013/03/26/on-transitivity/#comment-844223198

Original issue reported on code.google.com by [email protected] on 9 Apr 2013 at 6:19

Attachments:

• TransitivityFieldCheckerBrokenTest.java

[GoogleCodeExporter]

Fixed in version 1.3.1.

Original comment by [email protected] on 9 Jun 2013 at 3:23

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****