Тестовые примеры И утверждения утверждений

Проблема с доверием только к утверждениям заключается в том, что они могут быть отключены в производственной среде. Процитирую статью в Википедии:

Большинство языков позволяют включать или отключать утверждения глобально, а иногда и независимо. Утверждения часто включаются во время разработки и отключаются во время финального тестирования и при выпуске для клиента. Отсутствие проверки утверждений, что позволяет избежать затрат на оценку утверждений, в то время как, если предположить, что утверждения не имеют побочных эффектов, все же дает тот же результат в нормальных условиях. В ненормальных условиях отключение проверки утверждений может означать, что программа, которая была прервана, продолжит работу. Иногда это предпочтительнее. Википедия

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

Используйте утверждения для проверки входных данных, которыми вы управляете: частные методы и тому подобное.

Используйте операторы if для проверки ввода, который вы не контролируете: общедоступные интерфейсы, предназначенные для использования пользователем, тестирование ввода пользователем и т. Д.

Протестируйте свое приложение с помощью встроенных утверждений. Затем выполните развертывание без утверждений.

В некоторых случаях утверждения отключены при сборке для выпуска. У вас может не быть контроля над этим (в противном случае вы могли бы строить с утверждениями), поэтому было бы неплохо сделать это таким образом.

Проблема с «исправлением» входных значений заключается в том, что вызывающий объект не получит того, чего ожидает, и это может привести к проблемам или даже сбою в совершенно разных частях программы, что делает отладку кошмаром.

Я обычно бросаю исключение в if-statement, чтобы взять на себя роль утверждения, если они отключены.

assert(value>0);
if(value<=0) throw new ArgumentOutOfRangeException("value");
//do stuff

Я бы не согласился с этим утверждением:

Только вызывающий знает, что такое «допустимое входное значение» для вашей функции, и он должен проверить его действительность, прежде чем он вызовет вашу функцию.

Вызывающий может подумать, что он знает, что введенное значение верное. Только автор метода знает, как он должен работать. Лучшая цель программиста - заставить клиента попасть в "яму успеха ". Вы должны решить, какое поведение более уместно в данном случае. В некоторых случаях неправильные входные значения могут быть простительны, в других вы должны выдать исключение \ вернуть ошибку.

Что касается Asserts, я повторю других комментаторов, assert - это проверка времени отладки для автора кода, а не для клиентов кода.

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

Если, с другой стороны, вы не пишете логику для обработки всех случаев (возможно, потому, что неразумно пытаться продолжать с недопустимым вводом), то я бы использовал оператор утверждения и выбрал подход «раннего отказа».

Если я правильно помню из CS-класса

Предварительные условия определяют, при каких условиях определяется вывод вашей функции. Если вы сделаете свою функцию обработкой errorconditions, ваша функция определена для этих условий, и вам не нужен оператор assert.

Я согласен. Обычно и то, и другое не требуется.

Как прокомментировал Рик, это может вызвать проблемы, если вы удалите утверждения в выпущенном коде. Обычно я этого не делаю, за исключением мест, где производительность критична.

Я должен был сказать, что мне известно о том, что asserts (здесь) исчезают в производственном коде.

Если оператор if на самом деле исправляет недопустимые входные данные в производственном коде, это означает, что утверждение никогда не срабатывало во время тестирования отладочного кода, это означает, что вы написали код, который никогда не выполняли.

Для меня это ИЛИ ситуация:

(цитата Эндрю) «защитите от всех диапазонов недопустимого ввода, я бы не стал утруждать себя утверждением». -> напишите if-test.

(цитата аку) «неправильные входные значения простительны» -> напишите утверждение.

Я не могу стоять одновременно ...

Для внутренних функций, которые будете использовать только вы, используйте только утверждения. Утверждения помогут отловить ошибки во время тестирования, но не повлияют на производительность в продакшене.

Проверьте входные данные, исходящие извне, с помощью условий if. Внешне это где угодно за пределами кода, который вы / ваша команда контролируете и тестируете.

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

Проблема с утверждениями заключается в том, что они могут (и обычно будут) компилироваться из кода, поэтому вам нужно добавить обе стены на случай, если компилятор выбросит одну из них.