Hamcrest, JUnit и Eclipse: сообщения об ошибках перевернуты

В настоящее время я запускаю Hamcrest 1.3RC поверх JUnit 4 поверх Eclipse Helios, и есть только одна вещь, которая меня беспокоит в Hamcrest: сообщения об ошибках неправильные. Вместо «Ожидаемое: ‹ ожидаемое значение >, но было: ‹ фактическое значение >» я получаю «Ожидаемое: ‹ фактическое значение>, но было: ‹ ожидаемое значение >».

Я имею в виду, что это не так уж важно, но да ладно ^^ Неужели никто из разработчиков Hamcrest, которые во всех остальных отношениях проделывают такую ​​большую работу, не заметил этого? Или это ошибка, уникальная для моей среды? Просто скажите мне, есть ли у вас это тоже или нет, или даже лучше, вы знаете способ исправить эту ошибку.

Я пробовал это с Hamcrest 1.2 и 1.3RC, но ни один из них не работал правильно. TIA для любой подсказки.

Некоторый код для иллюстрации проблемы (имена частично немецкие, надеюсь, это не имеет значения):

Produkt p2 = pdao.getProdukt("Kekse");
assertNotNull(p2);
assertEquals(p2.getName(), "Kekse");
assertThat(p2.getPreis().doubleValue(), closeTo(2.57, 0.01));
assertEquals(p2.getFuellmenge(), 200);
assertEquals(p2.getFuelleinheit(), "G");
assertEquals(p2.isUeber18(), false);
assertEquals(p2.isAktiv(), true);

[EDIT2] Использование исключительно Hamcrest решило проблему. С этого момента я буду избегать assertEquals(...,...) в пользу assertThat(... is(...)).


person Hinton    schedule 13.03.2011    source источник
comment
Как насчет кода, позволяющего воспроизвести проблему?   -  person Michael Borgwardt    schedule 13.03.2011
comment
Я согласен с Дэвидом Харкнессом. Скорее всего, вы используете порядок параметров методов утверждения JUnit, а Hamcrest изменил его.   -  person Mikezx6r    schedule 16.03.2011
comment
Извините, что не ответил. Я ожидал получать уведомления по электронной почте о комментариях, но, по-видимому, этот вариант учитывается только для ответов. Я собираюсь включить код.   -  person Hinton    schedule 17.03.2011


Ответы (2)


Я использую Hamcrest как для Java, так и для PHP, и у меня нет этой проблемы. Я подозреваю, что вы передаете ожидаемое значение перед фактическим значением, которое является старым способом xUnit утверждать вещи. Hamcrest выбирает более удобочитаемую структуру.

Вот упрощенное объявление для MatcherAssert.assertThat():

void assertThat(T actual, Matcher<T> matcher)

Передайте фактическое значение, за которым следует средство сопоставления, связывающее его с ожидаемым значением. При желании вы можете передать более описательное сообщение перед фактическим значением.

void assertThat(String reason, T actual, Matcher<T> matcher)

Вот несколько примеров:

assertThat(add(2, 4), is(6));
assertThat($fruit->hasSeeds(), is(true));
assertThat($fruit->getColor(), containsString('red'));

Всегда указывайте исходный код в своем вопросе. Это увеличивает ваши шансы на ответ и, что более важно, на правильный ответ. ;)

person David Harkness    schedule 16.03.2011
comment
ОК, я последовал вашему совету по использованию assertThat(,is()) в пользу assertEquals, а также включил некоторый код. Хорошо, это сработало. Проблема была и была на самом деле только с JUnit assertEquals, Hamcrest не имеет к этому никакого отношения, поэтому с этого момента я собираюсь пропустить методы assertEquals(). - person Hinton; 17.03.2011

Прочтите документы API:

http://www.junit.org/apidocs/org/junit/Assert.html

Все методы JUnit assertXxx сначала имеют ожидаемое значение, а второе — фактическое значение. Вы просто вызываете метод с параметрами в неправильном порядке.

Пытаться

assertEquals("Kekse", p2.getName());

и вы будете в порядке.

В целом это хороший совет: прочитайте документацию перед использованием API;)

person Frans    schedule 11.01.2012