ТЛ; др
- Да, используйте тестирование утверждений в производстве , где это имеет смысл.
- Используйте другие библиотеки ( JUnit , AssertJ , Hamcrest и т. Д. .) вместо встроенного
assert объекта, если хотите.
Большинство других Ответов на этой странице выдвигают максиму «Утверждения, как правило, не используются в производственном коде». Хотя это верно в приложениях для повышения производительности, таких как текстовый процессор или электронная таблица, в пользовательских бизнес-приложениях, где так широко используется Java Тестирование утверждений на производстве чрезвычайно полезно и распространено.
Как и многие максимы в мире программирования, то, что начинается с истины в одном контексте, неправильно истолковывается, а затем неправильно применяется в других контекстах.
Приложения для повышения производительности
Этот принцип «Утверждения, как правило, не используются в производственном коде», хотя и распространен, неверен.
Формализованное тестирование утверждений, созданное с помощью таких приложений, как текстовый процессор, например Microsoft Word , или электронной таблицы, например Microsoft Excel . Эти приложения могут вызывать массив подтверждений проверок утверждений при каждом нажатии клавиши , сделанной пользователем. Такое экстремальное повторение сильно повлияло на производительность. Таким образом, только бета-версии таких продуктов в ограниченном выпуске имели включенные утверждения. Таким образом, максим.
Бизнес-приложения
Напротив, в бизнес-ориентированных приложениях для ввода данных, базы данных или другой обработки данных использование проверки утверждений на производстве чрезвычайно полезно. Незначительный удар по производительности делает его весьма практичным - и обычным делом.
Проверка бизнес-правил
Проверка ваших бизнес-правил во время выполнения в производстве является вполне разумной, и ее следует поощрять. Например, если в счете-фактуре всегда должно быть одно или несколько элементов строки, запишите проверку утверждений, если число элементов счета-фактуры больше нуля. Если имя продукта должно быть не менее 3 символов или более, напишите утверждение, проверяющее длину строки. Такие испытания не оказывают существенного влияния на производительность в производстве.
Условия выполнения
Если ваше приложение ожидает, что определенные условия всегда будут выполняться, когда ваше приложение работает в рабочей среде, запишите эти ожидания в свой код в качестве проверочных тестов.
Если вы ожидаете, что эти условия могут в некоторых случаях привести к сбою, то не пишите тесты утверждений. Возможно, выбросить определенные исключения. Затем попытайтесь восстановить, где это возможно.
Sanity-чека
Проверка работоспособности во время выполнения в производстве также вполне разумна и должна поощряться. Тестирование нескольких произвольных условий, которые невозможно представить себе как неправду, спасло мой бекон в бесчисленных ситуациях, когда происходило какое-то странное событие.
Например, тестирование того, что округление никеля (0,05) до пенни привело к получению никеля (0,05) в определенной библиотеке, помогло мне стать одним из первых, кто обнаружил недостаток технологии с плавающей запятой, который Apple выпустила в их Библиотека Rosetta при переходе с PowerPC на Intel. Такой недостаток, достигающий публики, казался бы невозможным. Но, что удивительно, этот недостаток ускользнул от внимания первоначального поставщика, Transitive и Apple, а также разработчиков раннего доступа, тестировавших бета-версии Apple.
(Кстати, я должен упомянуть ... никогда не использовать с плавающей точкой для денег , использовать BigDecimal.)
Выбор рамок
Вместо того, чтобы использовать встроенное средство assert, вы можете рассмотреть возможность использования другой платформы утверждений. У вас есть несколько вариантов, в том числе:
Или гОЛЛ своего собственного. Сделайте небольшой класс для использования в вашем проекте. Как то так.
package work.basil.example;
public class Assertions {
static public void assertTrue ( Boolean booleanExpression , CharSequence message ) throws java.lang.AssertionError {
if ( booleanExpression ) {
// No code needed here.
} else { // If booleanExpression is false rather than expected true, throw assertion error.
// FIXME: Add logging.
throw new java.lang.AssertionError( message.toString() );
}
}
}
Пример использования:
Assertions.assertTrue(
localTime.isBefore( LocalTime.NOON ) ,
"The time-of-day is too late, after noon: " + localTime + ". Message # 816a2a26-2b95-45fa-9b0a-5d10884d819d."
) ;
Ваши вопросы
Они прибыли относительно поздно (Java 1.4), к тому времени многие люди уже установили свой стиль / привычку программирования на Java
Да, это совершенно верно. Многие были разочарованы API, разработанным Sun / JCP для проверки утверждений. Его дизайн был тусклым по сравнению с существующими библиотеками. Многие игнорировали новый API и придерживались известных инструментов (сторонних инструментов или мини-библиотеки, созданной самим собой).
Они отключены во время выполнения по умолчанию, ПОЧЕМУ ОЙ, ПОЧЕМУ ??
В самые ранние годы Java получила плохую репутацию из-за низкой скорости работы. По иронии судьбы, Java быстро превратилась в и стала одной из лучших платформ для повышения производительности. Но плохой рэп тянулся как вонючий запах. Поэтому Sun крайне настороженно относится ко всему, что может каким-либо измеримым образом повлиять на производительность. Поэтому с этой точки зрения имеет смысл сделать по умолчанию отключение проверки утверждений.
Другая причина отключения по умолчанию могла быть связана с тем фактом, что при добавлении нового средства подтверждения Sun похитила слово assert. Это было , а не ранее зарезервированное ключевое слово, и требовало одного из немногих изменений, когда-либо внесенных в язык Java. Имя метода assert использовалось многими библиотеками и многими разработчиками в своем собственном коде. Чтобы обсудить этот исторический переход, прочитайте эту старую документацию Программирование с утверждениями .