Делает ли TDD защитное программирование избыточным?

Сегодня у меня была интересная беседа с коллегой.

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

В конкретной ситуации, в которой у меня было сегодняшнее обсуждение, я написал код, который проверяет правильность аргументов моего конструктора (например, целочисленный параметр должен быть> 0), и если предварительное условие не выполняется, генерируется исключение. Мой коллега, с другой стороны, считает, что такая проверка избыточна, потому что модульные тесты должны выявлять любые неправильные использования класса. Кроме того, он считает, что проверки защитного программирования должны также подвергаться модульному тестированию, поэтому защитное программирование добавляет много работы и поэтому не является оптимальным для TDD.

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

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

Никакая методология не может заставить пользователей правильно использовать код.

Там является небольшой аргумент , который будет сделан , что если вы отлично сделали TDD вы бы поймали чек> 0 в тестовом случае, до его реализации, и это имя - вероятно, вы добавив чек. Но если бы вы сделали TDD, ваше требование (> 0 в конструкторе) сначала появилось бы как неудачный тестовый сценарий. Таким образом, давая вам тест после добавления вашего чека.

Также разумно протестировать некоторые защитные условия (вы добавили логику, почему бы вам не захотеть протестировать что-то, что можно легко проверить?). Я не уверен, почему вы, кажется, не согласны с этим.

Или эти две техники дополняют друг друга?

TDD разработает тесты. Реализация проверки параметров заставит их пройти.

Защитное программирование и модульные тесты - это два разных способа выявления ошибок, каждый из которых имеет свои сильные стороны. Использование только одного способа обнаружения ошибок делает ваши механизмы обнаружения ошибок хрупкими. Использование обоих будет отлавливать ошибки, которые могли быть пропущены одним или другим, даже в коде, который не является открытым API; например, кто-то, возможно, забыл добавить модульный тест для неверных данных, переданных в общедоступный API. Проверка всего в соответствующих местах означает больше шансов поймать ошибку.

В области информационной безопасности это называется глубокой защитой. Наличие нескольких уровней защиты гарантирует, что если один не удастся, есть другие, чтобы поймать его.

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

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

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

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

Но разве мы не должны использовать тесты для выявления ошибок? Утверждения и тесты дополняют друг друга. Хорошая стратегия тестирования будет сочетать различные подходы для обеспечения надежности программного обеспечения. Только модульное тестирование или только интеграционное тестирование или только утверждения в коде - все это неудовлетворительно, вам нужна хорошая комбинация для достижения достаточной степени уверенности в вашем программном обеспечении с приемлемыми усилиями.

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

Есть тесты для поддержки и обеспечения защитного программирования

Защитное программирование защищает целостность системы во время выполнения.

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

РЕДАКТИРОВАТЬ: аналогия

А как насчет аналогии с комментариями в коде?

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

Допустим, вы вложили в тесты много внутренних знаний о вашей кодовой базе, например, MethodA не может принимать значение NULL, а аргумент MethodB должен быть > 0. Затем код меняется. Нуль в порядке для A сейчас, и B может принимать значения, такие как -10. Существующие тесты теперь функционально неверны, но будут продолжать проходить.

Да, вы должны обновлять тесты одновременно с обновлением кода. Вы также должны обновлять (или удалять) комментарии одновременно с обновлением кода. Но мы все знаем, что такие вещи не всегда случаются, и что ошибки сделаны.

Тесты проверяют поведение системы. Это фактическое поведение присуще самой системе, а не присуще тестам.

Что возможно могло пойти не так?

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

Что означает, что оборонительное программирование - это главное .

TDD управляет защитным программированием, если тесты комплексные.

Больше тестов, вождение более оборонительного программирования

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

Хороший набор тестов будет передавать как хорошие, так и плохие аргументы функции / методу и ожидать согласованных результатов. Это, в свою очередь, означает, что тестируемый компонент будет использовать проверки предварительных условий (защитное программирование) для подтверждения переданных ему аргументов.

Вообще говоря ...

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

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

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

Это может привести к неожиданному поведению в какой-то совершенно другой части системы, в которую передается экземпляр класса, в некотором отдаленном географическом регионе после поставки программного обеспечения . И это именно то, чего мы на самом деле пытаемся избежать, верно?

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

Особенно, если программисты этой другой системы не защитили код.

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

Итак, поскольку мы проводим тестирование программного обеспечения, нам следует прекратить помещать операторы assert в производственный код, верно? Позвольте мне сосчитать, каким образом это неправильно:

1. Утверждения не являются обязательными, поэтому, если они вам не нравятся, просто запустите вашу систему с отключенными утверждениями.

2. Утверждения проверяют то, что тестирование не может (и не должно). Потому что тестирование должно иметь представление «черного ящика» вашей системы, в то время как утверждения имеют представление «белого ящика». (Конечно, так как они живут в нем.)

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

4. Утверждения могут отлавливать ошибки в коде тестирования. Сталкивались ли вы когда-нибудь с ситуацией, когда тест не пройден, и вы не знаете, кто не прав - рабочий код или тест?

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

6. Утверждения указывают на ошибки, на которые намекает только тестирование. Итак, ваш тест устанавливает некоторые обширные предварительные условия, вызывает некоторый длинный фрагмент кода, собирает результаты и обнаруживает, что они не соответствуют ожидаемым. При наличии достаточного количества неполадок вы в конечном итоге найдете, где именно что-то пошло не так, но утверждения, как правило, сначала найдут.

7. Утверждения уменьшают сложность программы. Каждая строка кода, которую вы пишете, увеличивает сложность программы. Утверждения и ключевое слово final( readonly) - единственные известные мне две конструкции, которые на самом деле уменьшают сложность программы. Это бесценно.

8. Утверждения помогают компилятору лучше понять ваш код. Пожалуйста, попробуйте это дома: void foo( Object x ) { assert x != null; if( x == null ) { } }ваш компилятор должен выдать предупреждение о том, что условие x == nullвсегда ложно. Это может быть очень полезно.

Выше было резюме поста из моего блога, 2014-09-21 "Утверждения и тестирование"

Я полагаю, что в большинстве ответов отсутствует критическое различие: это зависит от того, как будет использоваться ваш код.

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

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

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

Этот аргумент немного сбивает меня с толку, потому что когда я начал практиковать TDD, мои модульные тесты вида «объект реагирует <определенным образом>, когда <недопустимый вход>» увеличился в 2 или 3 раза. Мне интересно, как вашему коллеге удается успешно проходить подобные юнит-тесты без проверки его функций.

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

Другими словами, то, что делает TDD, не мешает вам нуждаться в проверочном коде, а помогает вам избежать его забвения .

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

Мне кажется, что аргумент таков:

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

Для меня этот аргумент имеет некоторую логику, но он слишком полагается на модульные тесты, чтобы охватить все возможные ситуации. Простой факт состоит в том, что 100% покрытие линии / ветви / пути не обязательно использует каждое значение, которое может передать вызывающий объект, тогда как 100% покрытие всех возможных состояний вызывающего абонента (то есть все возможные значения его входных данных) и переменные) вычислительно неосуществимо.

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

Имейте в виду, однако, что если вы задокументируете и протестируете поведение вашей функции при передаче значения <= 0, то отрицательные значения больше не будут недействительными (по крайней мере, не более недействительными, чем любой аргумент вообще throw, поскольку тоже задокументировано, чтобы выбросить исключение!). Абоненты имеют право полагаться на это защитное поведение. Если позволяет язык, возможно, это в любом случае лучший сценарий - функция не имеет «недопустимых входных данных», но вызывающие абоненты, которые ожидают, что функция не вызовет исключение, должны быть достаточно проверены модулем, чтобы убедиться, что они не передать любые значения, которые вызывают это.

Несмотря на то, что вы думаете, что ваш коллега несколько менее прав, чем большинство ответов, я прихожу к одному и тому же выводу: оба метода дополняют друг друга. Программируйте защиту, документируйте свои защитные проверки и проверяйте их. Работа является «ненужной», только если пользователи вашего кода не могут воспользоваться полезными сообщениями об ошибках, когда они делают ошибки. Теоретически, если они тщательно протестируют весь свой код перед интеграцией с вашим, и в их тестах никогда не будет ошибок, то они никогда не увидят сообщений об ошибках. На практике, даже если они используют TDD и внедрение полной зависимости, они все равно могут исследовать их во время разработки или в тестировании может быть ошибка. В результате они вызывают ваш код до того, как их код станет идеальным!

Публичные интерфейсы могут и будут использоваться неправильно

Заявление вашего коллеги «модульные тесты должны отлавливать любые неправильные использования класса» строго ложно для любого интерфейса, который не является закрытым. Если открытая функция может быть вызвана с целочисленными аргументами, то она может и будет вызываться с любыми целочисленными аргументами, и код должен вести себя соответствующим образом. Если сигнатура общедоступной функции принимает, например, тип Java Double, тогда все возможные значения - null, NaN, MAX_VALUE, -Inf. Ваши модульные тесты не могут отловить неправильное использование класса, потому что эти тесты не могут тестировать код, который будет использовать этот класс, потому что этот код еще не написан, может быть не написан вами и определенно выйдет за рамки ваших модульных тестов. ,

С другой стороны, этот подход может быть действителен для (возможно, гораздо более многочисленных) частных свойств - если класс может гарантировать, что какой-то факт всегда является истинным (например, свойство X не может быть нулевым, целочисленная позиция не превышает максимальную длину когда вызывается функция A, все необходимые структуры данных сформированы правильно), тогда может быть целесообразно избегать проверки этого снова и снова по соображениям производительности и вместо этого полагаться на модульные тесты.

Защита от неправильного использования - это функция , разработанная в связи с требованием к ней. (Не все интерфейсы требуют строгой проверки на предмет неправильного использования; например, очень узко используемые внутренние.)

Функция требует тестирования: действительно ли работает защита от неправильного использования? Цель тестирования этой функции - попытаться показать, что это не так: придумать какое-то неправильное использование модуля, которое не будет проверено его проверками.

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

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

Проверки при входе в какую-либо функцию верхнего уровня служат, в частности, для защиты слабого или плохо протестированного внутреннего кода от непредвиденных комбинаций параметров (например, если код хорошо протестирован, проверки не нужны: код может просто " погода "плохие параметры).

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

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

Единственная проблема заключается в том, что исключения более низкого уровня не относятся к интерфейсу более высокого уровня. Является ли это проблемой, зависит от требований. Если требование просто «функция должна быть устойчивой к неправильному использованию и вызывать какие-то исключения, а не сбой, или продолжать вычислять с использованием данных мусора», то фактически она может быть покрыта всей устойчивостью частей более низкого уровня, на которых она работает. встроенный.

Если у функции есть требование к очень конкретным, подробным сообщениям об ошибках, связанным с ее параметрами, то проверки более низкого уровня не удовлетворяют этим требованиям полностью. Они гарантируют только то, что функция каким-то образом взорвется (не продолжая неправильную комбинацию параметров, что приведет к мусору). Если код клиента написан специально для определения определенных ошибок и их обработки, он может работать неправильно. Клиентский код может сам получать в качестве входных данных данные, на которых основаны параметры, и он может ожидать, что функция проверит их и преобразует неверные значения в конкретные ошибки, как это задокументировано (так, чтобы они могли обрабатывать эти ошибки правильно), а не некоторые другие ошибки, которые не обрабатываются и, возможно, остановить образ программного обеспечения.

TL; Д.Р .: Ваш коллега, вероятно, не идиот; вы просто обсуждаете одну и ту же вещь с разных точек зрения, потому что требования не полностью собраны, и у каждого из вас есть свое представление о том, что такое «неписаные требования». Вы думаете, что когда нет особых требований к проверке параметров, вам все равно следует написать подробную проверку; коллега думает, просто дайте надёжному коду нижнего уровня взорваться, если параметры неверны. Спорить о неписаных требованиях через код несколько непродуктивно: признайте, что вы не согласны с требованиями, а не с кодом. Ваш способ кодирования отражает ваши требования; путь коллеги отражает его взгляд на требования. Если вы видите это таким образом, ясно, что правильно или неправильно не т в самом коде; код является всего лишь прокси для вашего мнения о том, какой должна быть спецификация.

Тесты определяют контракт вашего класса.

Как следствие, отсутствие теста определяет контракт, который включает в себя неопределенное поведение . Поэтому, когда вы переходите nullк Foo::Frobnicate(Widget widget)невидимому хаосу во время выполнения, вы все еще находитесь в рамках контракта с вашим классом.

Позже вы решаете: «Мы не хотим возможности неопределенного поведения», что является разумным выбором. Это означает, что вы должны иметь ожидаемое поведение для перехода nullк Foo::Frobnicate(Widget widget).

И вы документируете это решение, включив

[Test]
void Foo_FrobnicatesANullWidget_ThrowsInvalidArgument() 
{
    Given(Foo foo);
    When(foo.Frobnicate(null));
    Then(Expect_Exception(InvalidArgument));
}

Хороший набор тестов будет использовать внешний интерфейс вашего класса и гарантировать, что такие неправильные действия приводят к правильному ответу (исключение или то, что вы определяете как «правильный»). Фактически, первый тестовый пример, который я пишу для класса, - это вызов его конструктора с аргументами вне допустимого диапазона.

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

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

Тесты TDD будут ловить ошибки при разработке кода .

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

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

В качестве конкретного примера, предположим, что библиотека финансового кода была разработана с использованием TDD. Один из тестов может утверждать, что конкретное значение никогда не может быть отрицательным. Это гарантирует, что разработчики библиотеки не будут случайно использовать классы при реализации функций.

Но после того, как библиотека выпущена, и я использую ее в своей собственной программе, эти тесты TDD не мешают мне присвоить отрицательное значение (при условии, что оно выставлено). Границы проверки будут.

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

TDD и защитное программирование идут рука об руку. Использование обоих не является излишним, но фактически дополняет. Когда у вас есть функция, вы хотите убедиться, что функция работает, как описано, и написать тесты для нее; если вы не расскажете о том, что происходит, когда в случае плохого ввода, плохого возврата, плохого состояния и т. д. вы недостаточно надежно пишете свои тесты, и ваш код будет хрупким, даже если все ваши тесты пройдены.

Как инженер по встраиванию, мне нравится использовать пример написания функции, чтобы просто сложить два байта вместе и вернуть результат следующим образом:

uint8_t AddTwoBytes(uint8_t a, uint8_t b, uint8_t *sum); 

Теперь, если вы просто сделаете это, *(sum) = a + bэто будет работать, но только с некоторыми входами. a = 1и b = 2сделал бы sum = 3; однако, потому что размер суммы является байтом, a = 100и b = 200сделал бы sum = 44из-за переполнения. В C вы бы вернули ошибку в этом случае, чтобы показать, что функция не выполнена; исключение - это то же самое в вашем коде. Без учета сбоев или тестирования того, как их обработать, не будет работать долгое время, потому что, если эти условия возникают, они не будут обработаны и могут вызвать любое количество проблем.