2016-12-19 5 views
1

Я использую JUnit в Android Studio, и либо я полностью с видом что-то, или JUnit просто не работает правильно ... Я получил этот пример кода:Junit не правильно сравнивает объекты?

ChatContent testContent = new ChatContent(new ArrayList<ChatMessage>()); 
ChatContent testContent2 = new ChatContent(new ArrayList<ChatMessage>()); 
assertThat(testContent, equalTo(testContent2)); 

И когда я запустить тест, Я получаю сообщение об ошибке

java.lang.AssertionError: Expected: [...][email protected] but: was [...][email protected] Expected :[...][email protected]

Actual :[...][email protected]

Это не должно было случиться, потому что equalTo() только проверка на равенство и не верно равенство как == делает, верно?

ChatContent - это в основном просто класс, который содержит экземпляр List<ChatMessage>, он не делает ничего другого.

В настоящее время я использую jUnit, Mockito и Hamcrest (все обновленные) в моем проекте.

+4

ли вы переопределить '' equals' в ChatContent'? – khelwood

+1

== сравнивает ссылки. Это всегда будет ложным, если у вас есть два вызова нового. – duffymo

+0

@duffymo Он сравнивает, к чему относятся ссылки «redidrect». @hhelwood Нет, потому что это было необязательно. И я бы не считал хорошей практикой переопределять 'toString()', 'equals()' и т. Д. В каждом классе, который я создаю ... – Namnodorel

ответ

1

Вы должны прочитать Javadoc для звонков, которые вы используете, как здесь equalTo:

Создает Искателя, который соответствует, когда исследуемый объект логически равно заданному операндом, как определено путем вызова объекта. equals (java.lang.Object) на исследуемом объекте.

Итак, как и следовало ожидать: это не JUnit или Hamcrest, это некорректно. Что такое некорректно Ваши предпосылки. Вы предполагаете, что equalTo() будет таким же, как ==. И когда ваши наблюдения не соответствовали вашим ожиданиям; вы предположили, что реальность нарушена, вместо того, чтобы расспрашивать ваши собственные предположения.

Подсказка: в большинстве случаев это наоборот.

В этом смысле ответ: override equals() и hashCode(). Или решите, что вам не нужен такой тест. Оба пути будут работать; это зависит от вашего контекста, который подходит вам лучше.

+1

В целом, ответ правильный. Но так же, как я сделал неправильное предположение, вы сделали тоже ... Я просто не знал, что 'obj.equals (...)' по умолчанию использует '==' (что на самом деле сводится к этому 'equalsTo () 'Это то же самое, что и' == '... Когда' equals() 'не переоценивается, но я также и написал« либо я полностью игнорирую ». Я знаю, что настолько популярная структура, вероятно, не ошибается , но я также не смог обнаружить свою ошибку. Вот почему я спросил здесь и не представил отчет об ошибке в jUnit. Но, по общему признанию, название было легко понять неправильно. – Namnodorel

+0

В любом случае ... Рад, что мы могли бы понять это , – GhostCat

0

Метод по методу Hamcrest equalTo по умолчанию вызывает метод Object.equals() (ChatContent.equals() в вашем случае) Я согласен с khelwood, что вам придется переопределить .equals, чтобы получить желаемое поведение, re используя Hamcrest, я бы предложил CustomMatcher.

http://www.planetgeek.ch/2012/03/07/create-your-own-matcher/

Смежные вопросы