title: How should one unit test the hashCode-equals contract?
body: <p>In a nutshell, the hashCode contract, according to Java's object.hashCode():</p>
  
  <ol>
  <li>The hash code shouldn't change unless something affecting equals() changes</li>
  <li>equals() implies hash codes are ==</li>
  </ol>
  
  <p>Let's assume interest primarily in immutable data objects - their information never changes after they're constructed, so #1 is assumed to hold.  That leaves #2: the problem is simply one of confirming that equals implies hash code ==.</p>
  
  <p>Obviously, we can't test every conceivable data object unless that set is trivially small.  So, what is the best way to write a unit test that is likely to catch the common cases?</p>
  
  <p>Since the instances of this class are immutable, there are limited ways to construct such an object; this unit test should cover all of them if possible.  Off the top of my head, the entry points are the constructors, deserialization, and constructors of subclasses (which should be reducible to the constructor call problem).</p>
  
  <p>[I'm going to try to answer my own question via research.  Input from other StackOverflowers is a welcome safety mechanism to this process.]</p>
  
  <p>[This could be applicable to other OO languages, so I'm adding that tag.]</p>