Какова альтернатива использованию устаревшего метода Hamcrest is()?

В настоящий момент я использую следующий код для подтверждения значения boolean, однако метод org.hamcrest.Matchers.is() устарел.

assertThat(someValue, is(false));

Существует ли простой альтернативный синтаксис для проверки логических значений, не прибегая к assertTrue(), который дает вам плохие сообщения об ошибках, такие как "java.lang.AssertionError"

Изменить после получения комментариев/ответов

Мои первоначальные опасения были подняты, потому что Eclipse показывает следующий оператор импорта как устаревший

введите здесь описание изображения

При просмотре Hamcrest API есть 3 перегруженных варианта метода is(), только один из которых устарел.

Поэтому, чтобы прояснить комментарий от @mark и ответ от @matt, использование is(), которое я разместил выше, допустимо и не осуждается.


java unit-testing hamcrest
person Brad    schedule 26.09.2012    source источник
comment
Это не устарело, я всегда предпочитаю is() вместо equalTo() для логических значений. Но они псевдонимы друг для друга.   -  person Mark Peters    schedule 26.09.2012
comment
Вы можете включить * вместо именования каждого сопоставителя для краткости и во избежание предупреждения.   -  person David Harkness    schedule 27.09.2012
comment
@David ... пока вы не используете «Организовать импорт»   -  person Brad    schedule 27.09.2012
comment
@Brad Установите Number of static imports needed for .* на 1.   -  person David Harkness    schedule 08.08.2014
comment
Ребят, а здесь вывод, что это баг в Eclipse? Я постоянно вижу это зачеркивание при статическом импорте.   -  person davidfrancis    schedule 01.12.2016
comment
В Eclipse нет ошибок. Смотрите мой комментарий к принятому ответу ниже. Существует много перегруженных методов с именем is(), только некоторые из них устарели.   -  person Brad    schedule 02.12.2016

Ответы (3)


arrow_upward
49
arrow_downward

Вы пробовали equalTo(T)?

assertThat(someValue, equalTo(false));

Я не вижу этого is(T) устарело - is(Class) однако устарелоd.

person matt b    schedule 26.09.2012
comment
Благодарю за разъяснение. Вы правы, is(T) не устарело. Я вижу, что его перегруженный брат is(Class<T>) устарел, что заставило меня поверить, что все виды использования is() устарели. - person Brad; 27.09.2012

arrow_upward
10
arrow_downward

Я думал, что это проблема транзитивной зависимости, но на самом деле это просто проблема с отображением в Eclipse, когда он помечает импорт как устаревший, потому что одна перегруженная форма. Код должен компилироваться нормально, так как импорт выставит все формы.

Устаревшая форма была удалена из источника и не будет существовать в следующем выпуске (1.4).

Исходный ответ

Проблема в том, что JUnit включает набор классов Hamcrest в свой JAR. На данный момент вы можете использовать junit-dep.jar, но более новые версии (4.9 и 4.10 пока) JUnit их опускают.

person David Harkness    schedule 27.09.2012
comment
Это проблема, но как это связано с этим вопросом? Я использую junit-4.11, и я все еще получаю это. В hamcrest-1.3 присутствуют все три упомянутых метода. Тот, который находится первым в порядке, в котором их находит затмение, является устаревшим, а AFAICT - это тот, который затмение помечает как устаревший. Интересно, что он расположен ниже других в исходном файле. - person aron; 07.08.2014
comment
@aron Я обновил свой ответ теперь, когда вижу, что это просто проблема с отображением Eclipse. - person David Harkness; 08.08.2014

arrow_upward
3
arrow_downward

Говорят, используйте instanceOf для сопоставления классов в документе.

http://junit.org/javadoc/latest/org/hamcrest/core/Is.html#isA(java.lang.Class)

is(IOException.class);

будет

is(instanceOf(IOException.class));

Например.

person shinpei    schedule 23.02.2015