The assertion is made on the value of the private field being the one expected after the method under test has been invoked. If the value is not what it’s expected to be, the test will break as it should. If a field with that name is no longer there, the test will break. As is should.
I would suggest there is no such thing as a ‘fragile test’. Tests are meant to break when the behavior they describe is not met.

In terms of good and bad practices:

When you want to test the value of a private field, you have three options:

- Expose a public getter on it or bend your application code to accommodate access, thus breaking encapsulation.

- Not test it, thus leaving a window for a potential bug to creep in.

- Reflect and assert on it.

To everyone who gets phased by reflection:

If you’ve ever used Spring, WebWork, Hibernate, JMock (… and the list goes on and on, way beyond Java frameworks), I’ve got bad news for you: Your applications are ‘fragile’, because most frameworks out there use reflection all over the place.

Just because reflection is dangerous in the hands of inexperienced developers, as are most powerful techniques, it doesn’t mean it’s bad. Fire burns, but there’s a million useful things you can do with it if you know how.

Don’t buy the reflection FUD just because somebody told you they got burned by it. Learn how to use it properly instead.

Admitted, in a unit test on the object I may want to test that when I say a.equals(b) that the equality is determined by a set of _particular_ fields.

I completely agree with you when you say ‘Equality is an integral attribute of a Class’s behavior and should be strictly meaningful under the context of the Class’s definition.’, but, I’m not sure I see why tests that assertEquals are wrong, if indeed you are trying to assert an object’s equality. Your tests are revealing your intention for the code, and there’s just no getting around the fact your looking for equality.

Through interfaces (or even those crazy superclass things), one object can have many public members, but they aren’t accessible everywhere (without crazy casting).

So if you have ComplexObject, an interface, you could have your implementation expose the fields, and only have your automated tests call the implementation directly.

A further problem is ‘exhausting testing’. I don’t mean ‘exhaustive testing’. It’s impossible to write complete (exhaustive) tests for most code. You end up testing some things, not quite at random, but often just according to what’s easiest to test.

In fact, you can end up just duplicating the ‘real’ code. I’d suggest instead to make sure that the tests exercise code that is used by users, i.e., don’t write tests that test things that can’t happen in a live environment.

That doesn’t mean you shouldn’t write tests that probe behaviour under strange situations, but you shouldn’t bother doing that if those strange situations can be filtered out instead. Instead of *exhausting* yourself trying to write exhaustive tests, write better application code.

>I’m thinking more that Java should have Object.equals() and Object.same()

It is not just Hibernate that requires this behavior, the JCF does too, which is integral to java. Java already has == for references, equals is meant to test semantic equivalence. What could same() possibly test for? If you wanted different levels of equality, then declare your own.

btw, Junit-objects offers reflective assertion via expressions on beans:

http://junit-objects.sourceforge.net

Jim

What is a specific example of a reasonably scoped Class that should not have equals/hashCode behaviour based on values?

Alex mentioned Hibernate in his blog entry but that’s only because Hibernate is forcing your object’s equals definition to be an entity equals instead of a values equals.

I’m thinking more that Java should have Object.equals() and Object.same()

I read your post and totally agree. I always had this doubt about equals/hashCode and object behavior. Thanks a lot!!

I added some comments at my blog: http://www.jroller.com/page/alexRuiz?entry=don_t_break_oo_in

Best regards,
Alex.