Почему я должен использовать Hamcrest-Matcher и assertThat () вместо традиционного assertXXX () - Методы
Вы можете также Программа uuencode Вы исходные двоичные данные. Этот формат является немного более старым, но он делает то же самое как base63 кодирование.
2 ответа
В примечаниях к выпуску JUnit для версии 4.4 (где он был представлен) указаны четыре преимущества:
- Более удобочитаемость и возможность ввода: это синтаксис позволяет вам мыслить в терминах субъекта, глагола, объекта (assert «x is 3»), а не assertEquals , который использует глагол, объект, субъект (assert «равно 3 x»)
- Комбинации : любой оператор сопоставления s может быть инвертирован ( not (s) ), объединен ( либо (s) .or (t) ), отображен в коллекцию ( каждый ( s) ) или используются в пользовательских комбинациях ( afterFiveSeconds (s) )
- Читаемые сообщения об ошибках. (...)
- Пользовательские сопоставители. Реализуя интерфейс Matcher самостоятельно, вы можете получить все вышеперечисленные преимущества для ваших собственных пользовательских утверждений.
Более подробная аргументация от парня, создавшего новый синтаксис: здесь .
Нет большого преимущества в тех случаях, когда существует assertFoo , который точно соответствует вашему намерению. В этих случаях они ведут себя почти одинаково.
Но когда вы переходите к более сложным проверкам, тогда преимущество становится более заметным:
assertTrue(foo.contains("someValue") && foo.contains("anotherValue"));
по сравнению с
assertThat(foo, hasItems("someValue", "anotherValue"));
. Можно обсудить, какой из них легче читать , но как только assert завершится неудачно, вы получите хорошее сообщение об ошибке от assertThat , но только очень минимальный объем информации от assertTrue .
assertThat сообщит вы, каково было утверждение и что вы получили вместо него. assertTrue сообщит вам только то, что вы получили false , где ожидали true .