assert против утверждений JUnit

85

Сегодня я увидел тестовый пример JUnit с утверждением java вместо утверждений JUnit - есть ли существенные преимущества или недостатки в предпочтении одного над другим?

— Роберт
источник

Между утверждениями JUnit и ключевым словом assert в Java есть абсолютно фактические различия. Это вовсе не вопрос, основанный на мнении.

— Thomas W

95

В JUnit4 исключение (на самом деле Error), вызванное утверждением JUnit, совпадает с ошибкой, вызванной assertключевым словом java (AssertionError), поэтому оно точно такое же, как assertTrueи трассировка стека, и кроме трассировки стека, вы не могли заметить разницу.

При этом утверждения должны запускаться со специальным флагом в JVM, в результате чего многие тесты кажутся пройденными только потому, что кто-то забыл настроить систему с этим флагом при запуске тестов JUnit - нехорошо.

В общем, из-за этого я бы сказал, что использование JUnit assertTrue- лучшая практика, потому что он гарантирует запуск теста, обеспечивает согласованность (вы иногда используете assertThatили другие утверждения, которые не являются ключевыми словами java), и если поведение JUnit утверждает должен измениться в будущем (например, подключиться к какому-либо фильтру или другой будущей функции JUnit), ваш код сможет это использовать.

Настоящая цель ключевого слова assert в java - отключить его без штрафа во время выполнения. Это не относится к модульным тестам.

— Ишай
источник

26

Я предпочитаю утверждения JUnit, поскольку они предлагают более богатый API, чем встроенный assertоператор, и, что более важно, не нуждаются в явном включении, в отличие от того assert, для чего требуется -eaаргумент JVM.

— Адамски
источник

1

-eaвсегда включен, в нем mvn testнет необходимости -ea. Более богатый апи, хороший улов. Иногда мне кажется, что API неправильно используется при тестировании, потому что он не является частью приложения (a в api), я предпочитаю называть его просто более богатыми методами.

— Grim

20

Когда тест не проходит, вы получаете дополнительную информацию.

assertEquals(1, 2); приводит к java.lang.AssertionError: expected:<1> but was:<2>

против

assert(1 == 2); приводит к java.lang.AssertionError

вы можете получить еще больше информации, если добавите аргумент сообщения в assertEquals

— стармер
источник

9

попробуй assert 1==2: "1 is not 2";.

— Мрачный

@PeterRader Попробуйте ключевое слово assert, если -ea не включен. Или еще лучше используйте утверждения JUnit, которые всегда работают.

— Thomas W

1

@ThomasW, когда -ea не включен, это не тест. Сборки JUnit не всегда работают, они работают только в том случае, если вы решите использовать JUnit, который является фреймворком, а в случае maven - зависимость maven, зависимость maven, которая должна быть только в тестовой области. У нас есть две стороны: что вы предпочитаете? 1-я сторона : используйте фреймворк как зависимость только в тестовой области, который должен быть загружен, это eclipse позволяет использовать в классах, которые не находятся в src / main-folder, но не будут компилироваться там, потому что maven имеет junit только в test- область или 2-я сторона : используйте встроенный материал.

— Grim

1

@PeterRader Этот вопрос касается тестовых примеров JUnit. В этом контексте следует использовать JUnit или аналогичный класс утверждений, потому что они всегда включены. Я лично был уличен в том, что ключевое слово Java assert не использовалось в прошлом, и я не верю, что ненадежные утверждения имеют место в тестовом коде.

— Thomas W

В отдельном контексте утверждений в коде функций - что важно для практики надежного программирования, хотя на самом деле это не тема вопроса - и Spring, и Google Guava имеют классы утверждений, которые всегда включены. Я рекомендую щедро использовать их в качестве предварительных условий параметров и состояний для обеспечения корректности. Помимо этого, в областях, критичных к производительности, может быть небольшая область, где Java assertможет быть предпочтительнее - для проверок правильности, которые могут повлиять на производительность и, следовательно, лучше всего отключены по умолчанию. Однако мой опыт показывает, что большинство утверждений должно быть постоянно.

— Thomas W

8

Я бы сказал, используйте утверждения JUnit в тестовых примерах и используйте утверждения Java в коде. Другими словами, реальный код никогда не должен иметь зависимостей JUnit, что очевидно, и если это тест, он должен использовать его варианты JUnit, а не assert.

— Бруно Д. Родригес
источник

0

Я бы сказал, что если вы используете JUnit, вам следует использовать утверждения JUnit. assertTrue()в основном то же самое, что и assert, иначе зачем вообще использовать JUnit?

— Сыр
источник

4

Вы должны использовать JUnit для среды выполнения тестов. Утверждения - действительно небольшая часть ценности, которую дает вам JUnit. Без JUnit Assertпотребуется больше шаблонов. assertбез JUnit вам потребуется написать целую структуру.

— Ишай

1

Я больше говорил, что если вы собираетесь использовать инструмент, ИСПОЛЬЗУЙТЕ ИНСТРУМЕНТ. обычные старые операторы assert кажутся немного глупыми в тестовых примерах JUnit. На мой взгляд, они соответствуют настоящему коду.

— CheesePls 03

1

@CheesePls «обычные старые утверждения assert» на самом деле более свежие, чем утверждает JUnit.

— дольмен

0

Это может не применяться, если вы используете исключительно блестящие и новые вещи, но assert не был введен в Java до 1.4SE. Следовательно, если вы должны работать в среде со старой технологией, вы можете склоняться к JUnit по соображениям совместимости.

— Дэн Коутс
источник