Junit4: assertTrue () / assertFalse () по умолчанию должен включать сообщение об ошибке

Будут ли полезны такие сообщения об ошибках по умолчанию? Вам нужно было бы взглянуть на тестовый код, чтобы понять, что пошло не так, не так ли?

Кстати, используйте org.junit.Assert вместо junit.framework.Assert .

Допустим, я пишу этот тест:

Пользователь user = ...;
assertTrue (user.isHappy ());
assertFalse (user.isSad ());

Тест завершается ошибкой AssertionError без сообщения. Невозможно определить, не проверив код и номера строк, какое утверждение не удалось.

Почему больше данных - это плохо?

Больше данных - неплохая вещь. Однако в этом случае я могу увидеть лишь немного больше данных.

Хотя я не против этой просьбы о функции, я думаю, что в настоящее время есть более эффективные способы формулировать утверждения, например Hamcrest или Truth.

Тем не менее, я думаю, что если кто-то отправит запрос на перенос по этой проблеме, мы, вероятно, объединим его ... ;-)

@ junit-team / junit-committers Есть возражения?

Я, конечно, не согласен с этим :-)
https://github.com/google/truth/commit?author=kluever

Но у нас были люди в Google, которые не хотели использовать assertTrue / assertFalse из-за этого. Но конечно, я пришлю для этого пул-реквест.

:улыбка:

Вы можете отправить сообщение на assertTrue и assertFalse .

assertTrue("The user is not happy, but she should.", user.isHappy());
assertFalse("The user is sad, but she should not.", user.isSad());

Это сообщение отображается в трассировке стека.

java.lang.AssertionError: The user is not happy, but she should.
java.lang.AssertionError: The user is sad, but she should not.

@stefanbirkner Да, мне это хорошо известно, но почему бы не показать разумное сообщение об ошибке и для случая по умолчанию?

Мы уже делаем это для assertEquals (ожидаемого, фактического) ... поэтому вам не нужно писать:
assertEquals («Ожидаемый» + ожидаемый + «но был» + фактический, ожидаемый, фактический);

Хотя я согласен, что может быть полезно иметь лучшее сообщение об ошибке от assertTrue (), я не уверен, что "expected <true> but was <false>" лучше

Я считаю, что у @dsaff был некоторый исторический контекст.

Просто чтобы прояснить масштаб проблемы: "Ожидаетсяно был«намного лучше» из-за стилистического предпочтения какого-либо сообщения, а не из-за его отсутствия, а не потому, что он передает фактическую дополнительную информацию, верно?

Первоначальная идея дизайна заключалась в том, что составление сообщения об ошибке - это когнитивное отвлечение от рассматриваемого вопроса. Если я говорю assertTrue (list.isEmpty ()), я думаю о состоянии списка, а не о сравнительном тесте между логическими значениями. Таким образом, JUnit не может сказать ничего полезного и не должен ничего говорить.

Это причина за забором Честертона.

В этом случае, упомянутом выше, до сих пор нет действительно интересных данных:

assertTrue (user.isHappy ());
assertFalse (user.isSad ());

Причина того, что assertEquals имеет более информативное сообщение об ошибке, заключается в том, что он может сказать что-то более информативное, а именно, какое фактическое значение и ожидаемые значения _are_, которые часто не известны до времени выполнения.

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

Следствием текущего состояния является то, что у ряда разумных и умных разработчиков есть личная практика всегда писать assertEquals(true, expression()) вместо assertTrue(expression()) . Плюс, конечно, просить проверяемых сделать то же самое, помещать это в их руководства по стилю и т. Д. Это нас огорчает, потому что нам нравится простота кода, но я не думаю, что мы можем утверждать, что это число очень велико.

Я также думаю, что ответ на вводный вопрос Дэвида (последний комментарий) - однозначное «да». Единственный случай, когда предоставляется какая-либо фактическая информация, - это когда тестовый метод содержит ровно один assertTrue и ровно один assertFalse . Это не очень часто, _и_ есть трассировка стека, _и_ они могли бы предоставить сообщение ... это не очень много. Я думаю, это связано с тем, что исключение без сообщений просто слишком _bare._

@ junit-team / junit-committers Что мы собираемся делать с этой проблемой?

Что ж, я за его закрытие. Кевин, Курт, есть ли у кого-нибудь из вас достаточно энтузиазма, чтобы быть адвокатом защиты?

Я за его закрытие.

Я голосую за этот вопрос. Другие фреймворки поддерживают отображение реальной ценности, и это очень важно. Я просто не мог поверить, что JUnit настолько негибкий.

Я голосую за этот вопрос, так как важно иметь более информативное сообщение об ошибке для assertTrue и assertFalse. Из-за этого мы с коллегами неохотно используем assertTrue / assertFalse.

@ChaminW Вы можете использовать assertTrue("Some more specific message.", value); для более информативного сообщения об ошибке.