Почему junit ComparisonFailure не используется assertEquals (Object, Object)?

Question

В Junit 4 вы видите какой-либо недостаток для выброса ComparisonFailure вместо AssertionError, когда assertEquals (Object, Object) не удается?

assertEquals (Объект, Объект) бросает

• a ComparisonFailure, если ожидаемое и фактическое значение - String
• и AssertionError, если один из них не является строкой

AssertionError сообщение уже имеет форму

"expected:<"+ expected.toString() +"> but was <"+ actual.toString()

(через String.valueOf, см. Ниже метод junit-4.8.2, вызываемый Assert.assertEquals (Object, Object) для создания сообщения AssertionError):

static String format(Object expected, Object actual) {
    ...
    String expectedString= String.valueOf(expected);
    String actualString=   String.valueOf(actual);
    ...
    return formatted+"expected:<"+ expectedString +"> but was:<"+ actualString +">";

ComparisonFailure предоставляют гораздо более читабельный способ определения различий в диалоговом окне Eclipse или Intellij IDEA (FEST-Assert выбрасывает это исключение)

[Обновление: вопрос отредактирован, чтобы сосредоточиться на обсуждении ComparisonFailure / AssertionError.]

Answer 1

Мы начали со сравнения строк, потому что было очевидно, как сделать сообщение об ошибке более полезным.Мы никогда не расширяли ComparisonFailure на общие объекты, потому что не было понятно, как это сделать в общем виде.Как и предполагали другие, вы можете добавить специальные утверждения, если вы можете предоставить более качественные сообщения об ошибках или перейти на Hamcrest, который предоставляет общий механизм добавления полезных сообщений об ошибках.

С уважением,

Kent

Answer 2

Я думаю, что вы, безусловно, можете написать свой собственный метод assertEquals, чтобы сделать это без каких-либо значительных проблем, если это работает для вас.

Однако, в общем случае (с точки зрения разработчиков фреймворка), это хорошая идея, я не уверен. Часто объекты сбоя не имеют имплементации toString, и в этом случае сообщение об ошибке из IDE будет очень вводящим в заблуждение. У вас может сложиться впечатление, что сравнение проводилось по эталонному идентификатору, хотя, возможно, его и не было.

Другими словами, полезно, если объекты имеют значимую реализацию toString, в противном случае это может быть не так.

Answer 3

Я согласен с текущей реализацией JUnit, с двумя классами исключений. Главным образом потому, что это дает нам возможность дифференцировать проблемы сравнения (ComparisonFailure) и более «серьезные» проблемы несовместимости типов (AssertionError).

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