В Eclipse, как я вижу ввод в Assert.assertEquals, когда он терпит неудачу?

Question

Я не большой гуру в Eclipse, поэтому, пожалуйста, прости мою неуклюжесть.

В Eclipse, когда я вызываю Assert.assertEquals (obj1, obj2) и это не удается, как мне заставить IDE показывать мне obj1 и obj2?

Я использую JExample , но, думаю, это не должно иметь значения.

---

Редактировать : Вот что я вижу:

_{(источник: yfrog.com )}
.

Answer 1

1. Сравнение с трассировкой сбоев - непростая задача, когда ваш объект немного сложен.
2. Сравнение с отладчиком полезно, если вы не переопределили toString (). Решение остается очень утомительным, потому что вы должны осматривать каждый предмет с обеих сторон.

Плагин Junit Eclipse предлагает опцию в случае сбоя: «Сравнить фактическое с ожидаемым TestResult». Представление достаточно близко к классическим инструментам сравнения контента:

Проблема в том, что он доступен только тогда, когда вы пишете assertEquals() с String объектами (на скриншоте мы видим, что опция в углу не предлагается без класса String):

Вы можете использовать toString() на своем объекте в утверждении, но это не очень хорошее решение:

• во-первых, вы коррелируете toString() с equals(Object) ... изменение одного должно повлечь изменение другого.
• во-вторых, семантика больше не соблюдается. toString() должен возвращать полезный метод для отладки состояния одного объекта, а не для идентификации объекта в семантике Java (equals(Object)).

Мне кажется, что в плагине JUnit Eclipse отсутствует функция.
Если сравнение не удается, даже если мы сравниваем не String объекты, оно должно предложить сравнение двух объектов, которые полагаются на их метод toString().
Это может предложить минимальный визуальный способ сравнения двух неравных объектов.
Конечно, поскольку equals(Object) не обязательно соотносится с toString(), выделенные различия следует изучать нашими глазами, но это уже было бы очень хорошим основанием, и в любом случае это намного лучше, чем никакой инструмент сравнения.

Answer 2

Если информации в представлении JUnit вам недостаточно, вы всегда можете установить точку останова исключения, например, java.lang.AssertionError. При запуске теста отладчик остановится непосредственно перед тем, как на самом деле будет сгенерировано исключение.

Answer 3

Assert.assertEquals() поместит представление toString() ожидаемого и фактического объекта в сообщение AssertionFailedError, которое он выбрасывает, а eclipse отобразит это в части "трассировки сбоев" представления JUnit:

_{(источник: ibm.com )}

Если у вас есть сложные объекты, которые вы хотите проверить, вам придется использовать отладчик и установить точку останова внутри Assert.assertEquals()

Answer 4

FEST Assert отобразит диалоговое окно сравнения в случае ошибки подтверждения, даже если сравниваемые объекты не являются строками. Я объяснил это более подробно в моем блоге .

Answer 5

Что ты видишь?

Когда вы выполняете assertTrue () и он не работает, вы видите ноль.

Но когда вы выполняете assertEquals, он должен показывать вам, что он ожидал и что он на самом деле получил.

Если вы используете JUnit, убедитесь, что вы смотрите на представление JUnit и перемещаете мышь к неудачному тесту.

Answer 6

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

Это работает только со строками. В общем случае единственный способ увидеть реальную причину - это установить точку останова и войти в нее.