Як одна одиниця повинна перевірити контракт hashCode-дорівнює?

У двох словах, контракт hashCode, відповідно до об'єкта Java.hashCode ():

1. Хеш-код не повинен змінюватися, якщо не зміниться щось, що впливає на equals ()
2. equals () передбачає, що хеш-коди = =

Давайте припустимо, що інтерес насамперед стосується незмінних об’єктів даних - їх інформація ніколи не змінюється після їх побудови, тому передбачається, що №1 має місце. Залишається # 2: проблема полягає лише в тому, щоб підтвердити, що дорівнює, означає хеш-код ==.

Очевидно, що ми не можемо перевірити кожен мислимий об’єкт даних, якщо цей набір не є тривіально малим. Отже, який найкращий спосіб написати модульний тест, який, ймовірно, охоплює типові випадки?

Оскільки екземпляри цього класу незмінні, існує обмежений спосіб побудови такого об'єкта; цей одиничний тест повинен охоплювати їх усіх, якщо це можливо. Зверху моєї голови точками входу є конструктори, десеріалізація та конструктори підкласів (які повинні бути зведені до проблеми виклику конструктора).

[Я спробую відповісти на власне запитання за допомогою дослідження. Вхідні дані від StackOverflowers - це вітальний механізм безпеки для цього процесу.]

[Це може бути застосовним до інших мов OO, тому я додаю цей тег.]

EqualsVerifier - відносно новий проект з відкритим кодом, і він дуже добре справляється з тестуванням контракту equals. У нього немає проблем, які має EqualsTester від GSBase. Я б точно рекомендував це.

Моя порада полягала б у тому, щоб подумати, чому / як це може ніколи не виконуватися, а потім написати деякі модульні тести, які спрямовані на ці ситуації.

Наприклад, припустимо, у вас був спеціальний Setклас. Два набори рівні, якщо вони містять однакові елементи, але основні структури даних двох рівних наборів можуть відрізнятися, якщо ці елементи зберігаються в іншому порядку. Наприклад:

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

У цьому випадку порядок елементів у наборах може впливати на їх хеш, залежно від алгоритму хешування, який ви реалізували. Отже, це такий тест, який я б написав, оскільки він перевіряє той випадок, коли я знаю, що певний алгоритм хешування може дати різні результати для двох об’єктів, які я визначив рівними.

Ви повинні використовувати подібний стандарт із власним власним класом, яким би він не був.

Для цього варто використовувати ад'ютони junit. Перевірте клас EqualsHashCodeTestCase http://junit-addons.sourceforge.net/, ви можете розширити це і реалізувати createInstance та createNotEqualInstance, це перевірить правильність методів equals і hashCode.

Я б порекомендував EqualsTester від GSBase. Це робить в основному те, що ви хочете. У мене з цим є дві (незначні) проблеми:

• Конструктор виконує всю роботу, що я не вважаю доброю практикою.
• Це не вдається, коли екземпляр класу А дорівнює екземпляру підкласу класу А. Це не обов'язково є порушенням контракту рівності.

[На момент написання цієї статті було розміщено ще три відповіді.]

Повторюючи, мета мого запитання - знайти стандартні випадки тестів, що підтверджують це hashCodeта equalsузгоджуються між собою. Я підходжу до цього питання, щоб уявити загальні шляхи, якими рухаються програмісти під час написання відповідних класів, а саме незмінні дані. Наприклад:

1. Писав, equals()не пишучи hashCode(). Це часто означає, що рівність визначалася як рівність полів двох екземплярів.
2. Писав, hashCode()не пишучи equals(). Це може означати, що програміст шукав більш ефективний алгоритм хешування.

У випадку №2 мені здається, що проблема не існує. Жодних додаткових екземплярів не було зроблено equals(), тому додаткові екземпляри не повинні мати однакових хеш-кодів. У гіршому випадку хеш-алгоритм може призвести до гіршої продуктивності хеш-карт, що виходить за рамки цього питання.

У випадку №1, стандартний модульний тест передбачає створення двох екземплярів одного і того ж об'єкта з однаковими даними, що передаються конструктору, та перевірку рівних хеш-кодів. А як щодо помилкових спрацьовувань Можна вибрати параметри конструктора, які випадково дають рівні хеш-коди на тим не менш необгрунтованому алгоритмі. Одиничний тест, який прагне уникати таких параметрів, відповідав би духу цього питання. Ярлик тут полягає в тому, щоб перевірити вихідний код equals(), добре подумати і написати тест на основі цього, але, хоча це може знадобитися в деяких випадках, можуть бути і загальні тести, які ловлять загальні проблеми - і такі тести також виконують дух цього питання.

Наприклад, якщо у класі, що перевіряється (назвемо його Data), є конструктор, який приймає String, і екземпляри, побудовані з рядків, які отримують equals()екземпляри, які були equals(), то хороший тест, мабуть, перевірить:

• new Data("foo")
• інший new Data("foo")

Ми могли б навіть перевірити хеш-код new Data(new String("foo")), щоб змусити рядок не інтернувати, хоча це, швидше за все, дасть правильний хеш-код, ніж Data.equals()дасть правильний результат, на мій погляд.

Відповідь Елі Кортрайт - це приклад продумування способу розбити хеш-алгоритм на основі знання equalsспецифікації. Приклад спеціальної колекції є хорошим, оскільки користувальницькі Collections іноді з’являються, і вони досить схильні до обробки алгоритму хешування.

Це один з єдиних випадків, коли в тесті я мав би кілька тверджень. Оскільки вам потрібно протестувати метод equals, вам слід одночасно перевірити і метод hashCode. Отже, на кожному з ваших рівних методів тестування також перевіряйте контракт hashCode.

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());

І звичайно перевірка хорошого hashCode - це ще одна вправа. Чесно кажучи, я б не потрудився зробити подвійну перевірку, щоб переконатись, що hashCode не змінювався в тому ж запуску, таку проблему краще вирішити, схопивши її в огляді коду та допомогнувши розробнику зрозуміти, чому це не хороший спосіб писати методи hashCode.

Ви також можете використовувати щось подібне до http://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/EqualsTester.java для тестування equals і hashCode.

Якщо у мене є клас Thing, як і більшість інших, я пишу клас ThingTest, який містить усі модульні тести для цього класу. У кожного ThingTestє метод

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

і якщо Thingклас замінює hashCode і дорівнює, він має метод

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

Цей метод відповідає за перевірку всіх інваріантів, призначених для утримання між будь-якою парою Thingоб'єктів. ObjectTestМетод він делегує відповідає за перевірку всіх інваріантів , які повинні утримувати між будь-якою парою об'єктів. Як equalsі hashCodeє методами всіх об'єктів, цей метод перевіряє це hashCodeі equalsузгоджується.

Потім у мене є кілька методів тестування, які створюють пари Thingоб’єктів і передають їх парному checkInvariantsметоду. Я використовую розділення еквівалентності, щоб вирішити, які пари варто перевірити. Я зазвичай створюю кожну пару, щоб бути різними лише в одному атрибуті, плюс тест, який тестує два еквівалентні об'єкти.

У мене також іноді є checkInvariantsметод з 3 аргументами , хоча я вважаю, що це менш корисно для виявлення дефектів, тому я не часто це роблю