Re: [MO-java-dev] Is IsEqual testing for equality in the right order?

[Nat P. <nat...@b1...>]

From: "Vincent Tencé" <Vin...@ge...>
> I can follow your advice and implement my own constraint, but it looks
like
> the same constraint
> to me.

In my opinion, if there *is* a difference between a.equals(b) and
b.equals(a) for your objects, then a constraint that takes that into account
is *not* testing equality, but is testing for some broken implementation of
the equals method, and is therefore different from the IsEquals constraint.

Making a new constraint class would make this assumption (that the equals
method is broken) explicit in your tests, which is a good thing.

> The ExpectationValue class do it expected.equals(actual) so it's also make
> it easier to migrate to the new
> dynamic mock framework. Any opinion?

One reason that ExpectationValue implements expected.equals(actual) is so
that tests can create a new class for the expected value that test for
something other than equality in the equals method.  This breaks the equals
protocol and so is (in my opinion) a nasty hack that will bite back at some
time when you least expect it.  The Constraint interface is designed to let
you avoid using this hack by defining exact constraints over method
arguments that do not need to be transitive, symmetrical, etc.

Cheers,
            Nat.

_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661