Comment doit-on unité de tester le hashCode égal contrat?

Mon conseil serait de penser à pourquoi/comment cela pourrait jamais pas vrai, et puis écrire des tests unitaires qui cible les situations.

Par exemple, disons que vous avez une coutume Set classe. Deux ensembles sont égaux s'ils contiennent les mêmes éléments, mais il est possible que les données sous-jacentes des structures de deux ensembles égaux à varier si ces éléments sont stockés dans un ordre différent. Par exemple:

MySet s1 = new MySet( new String[]{"Hello", "World"} );
MySet s2 = new MySet( new String[]{"World", "Hello"} );
assertEquals(s1, s2);
assertTrue( s1.hashCode()==s2.hashCode() );

Dans ce cas, l'ordre des éléments dans les ensembles peuvent affecter leurs hachage, en fonction de l'algorithme de hachage vous avez mis en œuvre. C'est le genre de test que je ferais, car il teste le cas où je sais qu'il serait possible pour certains algorithme de hachage pour produire des résultats différents pour les deux objets que j'ai défini pour être égaux.

Vous devez utiliser une norme similaire avec votre propre classe, quelle qu'elle soit.

Je recommanderais le EqualsTester de GSBase. Il fait ce que vous voulez. J'ai deux (petits) problèmes avec elle si:

• Le constructeur fait tout le travail, que je ne considère pas être une bonne pratique.
• Il échoue lorsqu'une instance de la classe A est égal à une instance d'une sous-classe de la classe A. Ce n'est pas nécessairement une violation de l'est égal contrat.

C'est l'un des seuls cas où j'aurais de multiples affirme dans un test. Puisque vous avez besoin de tester la méthode equals vous devriez également vérifier la méthode hashCode en même temps. Donc sur chacun de vos méthode equals des cas de test à vérifier le hashCode contrat en tant que bien.

A one = new A(...);
A two = new A(...);
assertEquals("These should be equal", one, two);
int oneCode = one.hashCode();
assertEquals("HashCodes should be equal", oneCode, two.hashCode());
assertEquals("HashCode should not change", oneCode, one.hashCode());

Et bien sûr la vérification pour une bonne hashCode est un autre exercice. Honnêtement, je n'aurais pas pris la peine de faire le double vérifier que le hashCode n'était pas en train de changer dans la même exécution, ce genre de problème est mieux géré par l'attraper dans une revue de code et d'aider le développeur à comprendre pourquoi ce n'est pas une bonne façon d'écrire des méthodes hashCode.

Si j'ai une classe Thing, comme la plupart des autres dois-je écrire une classe ThingTest, qui détient tous les tests unitaires pour la classe. Chaque ThingTest a une méthode

 public static void checkInvariants(final Thing thing) {
    ...
 }

et si le Thing classe substitue hashCode et equals il a une méthode

 public static void checkInvariants(final Thing thing1, Thing thing2) {
    ObjectTest.checkInvariants(thing1, thing2);
    ... invariants that are specific to Thing
 }

Cette méthode est responsable de la vérification de tous invariants qui sont conçus pour tenir entre n'importe quelle paire de Thing objets. Le ObjectTest méthode il délégués est responsable de la vérification de tous les invariants qui doit contenir entre toute paire d'objets. Comme equals et hashCode sont des méthodes de tous les objets, cette méthode vérifie que hashCode et equals sont cohérentes.

J'ai ensuite quelques méthodes de test que créer des paires de Thing objets, et de les transmettre à l'paires checkInvariants méthode. J'utilise l'équivalence de partitionnement de décider ce que les paires sont intéressants. J'ai l'habitude de créer chaque paire d'être différent dans un seul attribut, en plus d'un test qui teste l'équivalent de deux objets.

J'ai aussi parfois un argument 3 checkInvariants méthode, bien que je trouve qu'il est moins utile dans findinf défauts, donc je ne fais pas cela souvent