Basic JUnit questions

[Rhino]

I think I understand the basics of using JUnit - I'm still using JUnit3
for the moment - but I want to ask some things that I don't find clear in
the documentation that I've found.

Would it be reasonable to say all of the following?

1. For each class that I develop, I should have one JUnit class that
extends TestCase and that this TestCase class should test each of the
methods in the class I developed?

2. When I look at the JUnit window in Eclipse to see the results of that
TestCase class, all of them should have a Green icon beside them? In
other words, should each test be written to show a positive result? That
would seem to make life a lot easier in one way: whenever I ran a
TestCase that was written that way, any bug would be easy to spot because
it didn't have the Green icon beside it.

3. Is a TestSuite just a group of TestCases that can all be invoked from
the same JUnit class? For instance, given a project Foo, would I
typically have a single TestSuite for Foo that, when invoked, runs the
TestCases for each of the classes that makes up Foo?

Basically, I'm having a bit of confusion over exactly how much you put in
each class that extends TestCase (sorry for the strange wording but I
want to distinguish between the class that is being tested and the class
that is doing the testing and don't know the most concise wording) and
what a TestSuite should comprise.

Also, I'm very uncertain about the individual methods in each class that
extends TestCase and what sorts of results they should return. Should all
test methods result in a Green icon?

I can see where that would be very convenient: you simply run the test
case and even if it has dozens of methods, you just scan down the list
and make sure all of them have Green icons. If they do, all your tests
just passed and you can move on to the next thing.

On the other hand, I'm not completely sure how to accomplish that. I'm
picturing a method like bar() which takes two input parameters. Whenever
the values of the two input parameters are valid, bar() should produce a
valid result, which I can predict and put in a test that would look like
this:

int actualResult = myclass.bar(4);
int expectedResult = 2;
assertTrue("The actual result, " + actualResult + ", does not equal the
expected result, " + expectedResult, actualResult==expectedResult);

But bar() also anticipates bad values for input parameters and throws
IllegalArgumentException for those. What would my test for that look
like? Any case I've ever written like that returns a Black icon. How
would I write a case involving an Exception so that it gives a Green icon
as the result?

 

[Eric Sosman]

I think I understand the basics of using JUnit - I'm still using JUnit3
for the moment - but I want to ask some things that I don't find clear in
the documentation that I've found.

Would it be reasonable to say all of the following?

1. For each class that I develop, I should have one JUnit class that
extends TestCase and that this TestCase class should test each of the
methods in the class I developed?

Sort of, I'd say. Private and even package-private classes
might get a waiver, the idea being that their "contracts" are only
with the public classes that "employ" them. Non-public nested
classes, same thing: If they're really just "implementation details"
of their containing classes, they might not need separate testing.
(For some inner classes, it won't be possible to test in isolation.)

"Each method" may be a overkill, too. Getters and setters come
to mind as "too simple to test" -- usually. I've never heard of
anyone writing a unit test for the hashCode()/equals() pair (their
agreement should be verified, but it's not clear that testing is
the best way to go about it).

[...] Whenever
the values of the two input parameters are valid, bar() should produce a
valid result, which I can predict and put in a test that would look like
this:

int actualResult = myclass.bar(4);
int expectedResult = 2;
assertTrue("The actual result, " + actualResult + ", does not equal the
expected result, " + expectedResult, actualResult==expectedResult);

But bar() also anticipates bad values for input parameters and throws
IllegalArgumentException for those. What would my test for that look
like? Any case I've ever written like that returns a Black icon. How
would I write a case involving an Exception so that it gives a Green icon
as the result?

try {
int actual = myclass.bar(invalid);
assertTrue("Got result " + actual + " from " + invalid
+ " instead of an exception", false);
}
catch (IllegalArgumentException ex) {
// Thanks; I needed that!
}

 

[Jim]

Sort of, I'd say. Private and even package-private classes
might get a waiver, the idea being that their "contracts" are only
with the public classes that "employ" them. Non-public nested
classes, same thing: If they're really just "implementation details"
of their containing classes, they might not need separate testing.
(For some inner classes, it won't be possible to test in isolation.)

"Each method" may be a overkill, too. Getters and setters come
to mind as "too simple to test" -- usually. I've never heard of
anyone writing a unit test for the hashCode()/equals() pair (their
agreement should be verified, but it's not clear that testing is
the best way to go about it).

<snip>

Have to disagree about equals() at least. Having a unit test for
equals ensures that when you make changes to your class you
don't break the method. As me how I know ;-)

Jim

 

[Daniel Pitts]

try {
int actual = myclass.bar(invalid);
assertTrue("Got result " + actual + " from " + invalid
+ " instead of an exception", false);
}
catch (IllegalArgumentException ex) {
// Thanks; I needed that!
}

I think there is a "fail(String )" method you can call instead of
assertTrue(String, false). At least, on the versions of JUnit I have used.

 

[Tom Anderson]

I think I understand the basics of using JUnit - I'm still using JUnit3
for the moment

I'd strongly advise moving to 4 right away - there are some differences to
get used to, so best to do that before you get comfortable with 3.

1. For each class that I develop, I should have one JUnit class that
extends TestCase and that this TestCase class should test each of the
methods in the class I developed?

There doesn't have to be a strict 1:1 relationship. Test classes are
classes, and are subject to the same principles of design as any other
classes - give each class a single responsibility, splitting classes that
do too many different things. A responsibility could be "test that the
Furnace class works", but it could also be "test that the Furnace class
incinerates various kinds of rubbish properly", where you'd then have
other classes to test other aspects of Furnace behaviour. You might also
want more integrationish tests, which would involve the interaction of two
classes - test that the ResourceLoader works properly when coupled to the
JDBCDataStore.

2. When I look at the JUnit window in Eclipse to see the results of that
TestCase class, all of them should have a Green icon beside them?

Yes, absolutely.

In other words, should each test be written to show a positive result?

Yes, absolutely.

That would seem to make life a lot easier in one way: whenever I ran a
TestCase that was written that way, any bug would be easy to spot
because it didn't have the Green icon beside it.

Bingo. Eclipse has a button - the little red and blue squares at the top
of the JUnit pane - that hides all green tests, leaving only failed and
errored ones, which makes it even easier to spot the troublemakers.

3. Is a TestSuite just a group of TestCases that can all be invoked from
the same JUnit class?
Yes.

For instance, given a project Foo, would I typically have a single
TestSuite for Foo that, when invoked, runs the TestCases for each of the
classes that makes up Foo?

Precisely.

Although you might have several suite classes, and you might nest them.
For instance, in our current project, we have an AllTests suite (this is
quite a common name for such a thing, i think) that runs all the tests
that are meaningful on a development machine. We have some extra tests
which only make sense on the nightly build (which does some extra tasks
which take longer, and which need to be tested), so we have a
ServerBuildTests suite. We then have a super-suite
AllTestsAndServerBuildTests, which runs both of the other suites. To be
honest, those names probably aren't quite right, but hey, at least we have
the tests.

Note that Eclipse doesn't require you to have a suite to run all your
tests - in the context menu for a source folder, there's Run As > JUnit
Test, which will find all the tests in that package and run them. You
can't use this in a non-Eclipse situation (like a command-line build, such
as you might distribute, or use for a nightly build), but there are
equivalents; i have build-and-test scripts which employ the following
science:

grep -rl --include='*.java' @Test "$TEST_SRC_DIR" | cut -d / -f 2- | cut -d . -f 1 | tr / . | xargs java -ea -classpath "$TEST_CLASSES_DIR:$CLASSES_DIR" org.junit.runner.JUnitCore

Basically, I'm having a bit of confusion over exactly how much you put
in each class that extends TestCase

There's no easy answer to this. On the bright side, there are no hard and
fast rules, so you can't get it wrong. Approach the matter as you would
any other question of how much should go in a class, but don't sweat it
too much. There tends to be fairly little coupling between test methods in
a test class, so it's not a disaster if the classes that contain them are
too big or too small. Where i work, our test classes very much tend to run
to the too big end of the scale rather than the too small - i think
there's one with thirty or so test methods. That really could do with
breaking up, actually.

(sorry for the strange wording but I want to distinguish between the
class that is being tested and the class that is doing the testing and
don't know the most concise wording)

I call that a test class. The target is the 'class under test'.

and what a TestSuite should comprise.

Also, I'm very uncertain about the individual methods in each class that
extends TestCase and what sorts of results they should return. Should
all test methods result in a Green icon?

Yes, absolutely. This is essential. Fundamental.

I can see where that would be very convenient: you simply run the test
case and even if it has dozens of methods, you just scan down the list
and make sure all of them have Green icons. If they do, all your tests
just passed and you can move on to the next thing.

Not just convenient, essential.

On the other hand, I'm not completely sure how to accomplish that. I'm
picturing a method like bar() which takes two input parameters. Whenever
the values of the two input parameters are valid, bar() should produce a
valid result, which I can predict and put in a test that would look like
this:

int actualResult = myclass.bar(4);

Hey, what happened to the other parameter?

int expectedResult = 2;
assertTrue("The actual result, " + actualResult + ", does not equal the
expected result, " + expectedResult, actualResult==expectedResult);

But bar() also anticipates bad values for input parameters and throws
IllegalArgumentException for those. What would my test for that look
like? Any case I've ever written like that returns a Black icon. How
would I write a case involving an Exception so that it gives a Green
icon as the result?

Under JUnit 4:

@Test(expected=IllegalArgumentException.class)
public void testBarThrowsExceptionForInvalidParameters() {
myclass.bar(-1);
}

Under JUnit 3:

public void testBarThrowsExceptionForInvalidParameters() {
try {
myclass.bar(-1);
}
catch (IllegalArgumentException e) {
return;
}
fail(); // this will only be reached if an exception is not thrown
}

Or some variation on that - the fail() could be inside the try, right
after the call to bar, or you could have a boolean exceptionThrown =
false, then set it to true in the catch block, then do
assertTrue(exceptionThrown) at the end.

HTH.

tom

 

[Rhino]

Sort of, I'd say. Private and even package-private classes
might get a waiver, the idea being that their "contracts" are only
with the public classes that "employ" them. Non-public nested
classes, same thing: If they're really just "implementation details"
of their containing classes, they might not need separate testing.
(For some inner classes, it won't be possible to test in isolation.)

"Each method" may be a overkill, too. Getters and setters come
to mind as "too simple to test" -- usually. I've never heard of
anyone writing a unit test for the hashCode()/equals() pair (their
agreement should be verified, but it's not clear that testing is
the best way to go about it).

I had a feeling that question was going to be a bit controversial ;-)

I asked a similar question a few weeks back and some people said that you
should test absolutely everything, even seemingly trivial code like
getters/setters. I don't recall ever having a bug in anything quite that
trivial so I'm still a little dubious about the merit of testing really
simple code but I can well imagine that an employer would insist on
testing absolutely EVERYTHING so maybe I should write my tests to that
standard....

I'm still not sure HOW to test some kinds of code but I'll ask about
those individually when that comes up. For now, I'm just trying to get
the basics down.

[...] Whenever
the values of the two input parameters are valid, bar() should
produce a valid result, which I can predict and put in a test that
would look like this:

int actualResult = myclass.bar(4);
int expectedResult = 2;
assertTrue("The actual result, " + actualResult + ", does not equal
the expected result, " + expectedResult,
actualResult==expectedResult);

But bar() also anticipates bad values for input parameters and throws
IllegalArgumentException for those. What would my test for that look
like? Any case I've ever written like that returns a Black icon. How
would I write a case involving an Exception so that it gives a Green
icon as the result?

try {
int actual = myclass.bar(invalid);
assertTrue("Got result " + actual + " from " + invalid
+ " instead of an exception", false);
}
catch (IllegalArgumentException ex) {
// Thanks; I needed that!
}

Now THAT is helpful! In fact, it means that I can consolidate all of the
testing for a given method into a single method in the TestCase class
rather than having a substantial number of tiny test methods for a given
method in the class I developed. And that's where I was hoping to end up
when I asked the question in the first place.

THANK YOU!!

 

[Rhino]

<snip>

Have to disagree about equals() at least. Having a unit test for
equals ensures that when you make changes to your class you
don't break the method. As me how I know ;-)

Jim

I've been lucky enough not to get burned by one of those yet - at least as
far as I know! - but you make a good point. Murphy's Laws, right? Anything
that can go wrong, will go wrong.

It probably makes sense to test even really trivial-looking code....

 

[Rhino]

I think there is a "fail(String )" method you can call instead of
assertTrue(String, false). At least, on the versions of JUnit I have
used.

You're absolutely right about that. I tried it the way Eric suggested
first, then tried it with the "fail(String)" that you mentioned here and
both worked perfectly.

Thank you!

 

[Eric Sosman]

[...]
"Each method" may be a overkill, too. Getters and setters come
to mind as "too simple to test" -- usually. I've never heard of
anyone writing a unit test for the hashCode()/equals() pair (their
agreement should be verified, but it's not clear that testing is
the best way to go about it).

<snip>

Have to disagree about equals() at least. Having a unit test for
equals ensures that when you make changes to your class you
don't break the method. As me how I know ;-)

Sorry if I wasn't clear: By referring to the "pair," I meant
trying to test that x.equals(y) -> x.hashCode() == y.hashCode(),
or that x.hashCode() != y.hashCode() -> !x.equals(y). Testing
equals() alone may make sense. Testing hashCode() alone almost
certainly doesn't. The implications must hold, but I'm not
convinced testing is the right way to verify that they do.

 

[Arne Vajhøj]

I think I understand the basics of using JUnit - I'm still using JUnit3
for the moment - but I want to ask some things that I don't find clear in
the documentation that I've found.

Would it be reasonable to say all of the following?

1. For each class that I develop, I should have one JUnit class that
extends TestCase and that this TestCase class should test each of the
methods in the class I developed?

That is the standard.

Unless you have a good reason to deviate, then follow that model.

2. When I look at the JUnit window in Eclipse to see the results of that
TestCase class, all of them should have a Green icon beside them? In
other words, should each test be written to show a positive result? That
would seem to make life a lot easier in one way: whenever I ran a
TestCase that was written that way, any bug would be easy to spot because
it didn't have the Green icon beside it.

Yes. I even believe that all green will be collapsed.

3. Is a TestSuite just a group of TestCases that can all be invoked from
the same JUnit class? For instance, given a project Foo, would I
typically have a single TestSuite for Foo that, when invoked, runs the
TestCases for each of the classes that makes up Foo?
Yes.

Basically, I'm having a bit of confusion over exactly how much you put in
each class that extends TestCase (sorry for the strange wording but I
want to distinguish between the class that is being tested and the class
that is doing the testing and don't know the most concise wording) and
what a TestSuite should comprise.

Also, I'm very uncertain about the individual methods in each class that
extends TestCase and what sorts of results they should return. Should all
test methods result in a Green icon?

I can see where that would be very convenient: you simply run the test
case and even if it has dozens of methods, you just scan down the list
and make sure all of them have Green icons. If they do, all your tests
just passed and you can move on to the next thing.

On the other hand, I'm not completely sure how to accomplish that. I'm
picturing a method like bar() which takes two input parameters. Whenever
the values of the two input parameters are valid, bar() should produce a
valid result, which I can predict and put in a test that would look like
this:

int actualResult = myclass.bar(4);
int expectedResult = 2;
assertTrue("The actual result, " + actualResult + ", does not equal the
expected result, " + expectedResult, actualResult==expectedResult);

But bar() also anticipates bad values for input parameters and throws
IllegalArgumentException for those. What would my test for that look
like? Any case I've ever written like that returns a Black icon. How
would I write a case involving an Exception so that it gives a Green icon
as the result?

try {
dosomethingbad();
fail("dosomething bad did not fail");
} catch(FoobarException ex) {
// expected
}

Arne

 

[Arne Vajhøj]

Sort of, I'd say. Private and even package-private classes
might get a waiver, the idea being that their "contracts" are only
with the public classes that "employ" them. Non-public nested
classes, same thing: If they're really just "implementation details"
of their containing classes, they might not need separate testing.
(For some inner classes, it won't be possible to test in isolation.)

"Each method" may be a overkill, too. Getters and setters come
to mind as "too simple to test" -- usually.

I recommend testing them as well.

They are easy to test and weird things have been seen in code before.

Arne

 

[Eric Sosman]

I think I understand the basics of using JUnit - I'm still using JUnit3
for the moment - but I want to ask some things that I don't find
clear in
the documentation that I've found.

Would it be reasonable to say all of the following?

1. For each class that I develop, I should have one JUnit class that
extends TestCase and that this TestCase class should test each of the
methods in the class I developed?

[...]
"Each method" may be a overkill, too. Getters and setters come
to mind as "too simple to test" -- usually.

I recommend testing them as well.

They are easy to test and weird things have been seen in code before.

Well, I *did* say "usually."

If setters are supposed to do something more than merely
set a value -- fire change events, say, or recompute allied
values other than the ones directly set -- that's worth testing.
If getters return arrays, it's worth verifying that mucking with
the returned array doesn't magically modify the state of the
object it came from (unless it's supposed to, in which case one
should test that it actually does). And so on, and so on.

But I put it to you that

public void setScrew(int screw) {
this.screw = screw;
}

.... is more amenable to verification by inspection than by test.

As to ease of testing, I note that the code to test a simple
getter or setter is more complex than the code tested; something
seems fundamentally wrong with this. If we think a one-liner
needs testing, why aren't we writing tests for the umpteen-line
test class?

 

[Daniel Pitts]

[...]
"Each method" may be a overkill, too. Getters and setters come
to mind as "too simple to test" -- usually. I've never heard of
anyone writing a unit test for the hashCode()/equals() pair (their
agreement should be verified, but it's not clear that testing is
the best way to go about it).

<snip>

Have to disagree about equals() at least. Having a unit test for
equals ensures that when you make changes to your class you
don't break the method. As me how I know ;-)

Sorry if I wasn't clear: By referring to the "pair," I meant
trying to test that x.equals(y) -> x.hashCode() == y.hashCode(),
or that x.hashCode() != y.hashCode() -> !x.equals(y). Testing
equals() alone may make sense. Testing hashCode() alone almost
certainly doesn't. The implications must hold, but I'm not
convinced testing is the right way to verify that they do.

if your objects behavior depends on correct functioning of that method
pair, then you should definitely unit test them.

At the very least, testing the first is important (x.equals(y) ->
x.hashCode() == y.hashCode()).

Actually, if you test that for all edge/general cases, then the second
one is probably irrelevant (or redundant)

 

[Tom Anderson]

I had a feeling that question was going to be a bit controversial ;-)

I asked a similar question a few weeks back and some people said that
you should test absolutely everything, even seemingly trivial code like
getters/setters. I don't recall ever having a bug in anything quite that
trivial so I'm still a little dubious about the merit of testing really
simple code

I'm not religious about this either. In particular, i often don't test all
trivial convenience constructors. If i have:

class CombineHarvester {
public CombineHarvester(int horsepower, HeadType head) {
// ...
}
public CombineHarvester(int horsepower) {
this(horsepower, HeadType.GRAIN_PLATFORM);
}
}

I might not test the second constructor.

However, you often test getters and setters in the course of testing other
methods. For example:

@Test
testOverdraftLimit() {
Account ac = new Account();
ac.setBalance(100000);
ac.setOverdraftLimit(20000);
int withdrawn = ac.withdraw(150000);
assertEqual(120000, withdrawn);
assertEqual(-20000, ac.getBalance());
}

That method is ostensibly about testing the overdraft limit logic, but it
depends on setBalance and getBalance working right. If they don't, it will
break, and you'll find out about it. Well, or they'll mask a bug in the
overdraft mechanism, and you won't find out about either bug, but that's
life.

tom

 

[Graham Cox]

I've been lucky enough not to get burned by one of those yet - at least as
far as I know! - but you make a good point. Murphy's Laws, right? Anything
that can go wrong, will go wrong.

It probably makes sense to test even really trivial-looking code....

I tend to think that any function with more than 2 lines of code should be
unit tested. This means that getters and setters are generally exempt *unless
they do something*. Specifically it means that the setters that do data
validation first should be tested, but the setters that do nothign more than
store the value to a member variable can be ignored...

 

[Eric Sosman]

[...]
Sorry if I wasn't clear: By referring to the "pair," I meant
trying to test that x.equals(y) -> x.hashCode() == y.hashCode(),
or that x.hashCode() != y.hashCode() -> !x.equals(y). Testing
equals() alone may make sense. Testing hashCode() alone almost
certainly doesn't. The implications must hold, but I'm not
convinced testing is the right way to verify that they do.

if your objects behavior depends on correct functioning of that method
pair, then you should definitely unit test them.

Usually it's not the object's own behavior, but the
behavior of a HashMap or similar that might use your object
as a key, possibly in some circumstance you didn't anticipate.

At the very least, testing the first is important (x.equals(y) ->
x.hashCode() == y.hashCode()).

Yeah, but how do you test it and have confidence? You can
create a bunch of equal objects and compare hashCodes, but how
do you know you've covered the space of all glitches? For
example, you might generate the String "Hello" as a literal
and again by assembling it in a StringBuilder, and find that
the two Strings' hashCodes are equal; that's fine. But what if
they had been six characters long instead of five, or if they'd
had some other genesis?

"How do you know when you've tested enough?" is, of course,
a question that besets all testing. But with respect to the
equals/hashCode pair, I suggest that code inspection is a
superior approach, because it can lead to complete confidence
instead of to "Well, I've never seen it misbehave." If you
can show that

1) The result of the equals() method depends only on the
instance variables of the two objects, and not on any
"external" datum (once class identity is satisfied), and

2) The result of the hashCode() method depends only on the
instance variables of one instance, and

3) The variables used by hashCode() are a subset of those
used by equals()

.... then you've *proved* the methods consistent. I submit that
a solid proof is preferable to anything testing can yield, and
that these methods are nearly always simple enough to make
proof not merely feasible but straightforward.

Actually, if you test that for all edge/general cases,

Knowing where the edge cases are requires knowledge of the
way the methods are implemented, or at the very least an informed
guess about the implementation. If you're willing to examine the
code to guide the writing of the test, it seems silly not to go
ahead and do the proof.

Ah, well: Different strokes for different folks.

then the second
one is probably irrelevant (or redundant)

The two implications are logically equivalent. There's an
old story about two friends who set out to test "All crows are
black." The first spent a lot of time and money, traveled the
wide world over looking for crows, and recorded that every crow
he saw was black. "Testing can't *prove* crowblackness," he said,
"but by examining a large sample of crows and finding all of them
black I have increased my level of confidence in the proposition."

The second guy was a logician, and observed that the statement
"All non-black things are non-crows" is logically equivalent to
the original: Prove either, and you have proved the other. So he
just sat back in his easy chair and let his eyes wander to non-black
things in his field of view, observing that every non-black thing he
saw was a non-crow. "Testing can't *prove* nonblacknoncrowness,"
he said, "but by examining a large sample of non-black things and
finding all of them to be non-crows I have increased my level of
confidence in both propositions. Plus, I've saved a lot of time
and money and have been lavishing it on my absent friend's main
squeeze, to our considerable enjoyment."

More prosaically, one of the implications might be easier to
test than the other.

 

[Graham Cox]

I use different criteria. The Eclipse "Source" code generation seems to
be well tested. If I merely told Eclipse to generate a setter or getter,
or the equals/hashCode pair, I don't write a test. If I wrote a getter
or setter myself, it needs testing. I'm fully capable of making a
mistake in a single line of code.

Fair point, but I was more getting at the fact that I *do* unit test
generated functions like equals and hashCode, simply because the class
often changes after they were generated and they are no longer
valid. Just because the code was correct at the time of writing
doesn't mean it will always remain so...

 

[Tom Anderson]

"How do you know when you've tested enough?" is, of course, a
question that besets all testing. But with respect to the
equals/hashCode pair, I suggest that code inspection is a superior
approach, because it can lead to complete confidence instead of to
"Well, I've never seen it misbehave."

How often do you propose to do this inspection, and how you propose to
ensure that it is done?

tom

 

[Graham Cox]

If I need to change the equality-relevant fields, and I'm using Eclipse
generation, I regenerate equals and hashCode with the new field
selection. If, for any reason, I had to edit either of them rather than
regenerating, I would add a unit test.

All very reasonable and correct, but can you guarantee that you
*always* regenerate the equals and hashcode methods when you change
the class? And do you update the equals and hashcode of all
subclasses as well? And all wrapper classes? (Admittadly, those last
two *should* use the equals/hashCode of the super/inner class in
question, but that doesn't always happen...) I find that the few
minutes to write a unit test to cover my equals/hashcode
implementations are cheap enough to be worth it for the - admittadly
very few - times it's actually found something, and is always nice for
a little bit extra peace of mind...

 

[Eric Sosman]

Fair point, but I was more getting at the fact that I *do* unit test
generated functions like equals and hashCode, simply because the class
often changes after they were generated and they are no longer
valid. Just because the code was correct at the time of writing
doesn't mean it will always remain so...

This is true: Sometimes "maintenance" and "enhancement"
are synonyms for "bit rot."

But I'm curious: What sort of a test do you write to ensure
that equals() and hashCode() play nicely together? For example,
if you were writing unit tests for java.lang.String, what would
they look like?