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

Ответ 1

В тех местах, где я ранее работал, модульное тестирование обычно используется в качестве причины для работы с небольшим отделом тестирования, логика "У нас есть тесты UNIT! Наш код не может завершиться неудачно!! у нас есть модульные тесты, нам не нужны настоящие тестеры!!" .

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

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

Теперь фанатам не понравится этот бит: место, где я работаю, в значительной степени ускользнуло с помощью модульных тестов, потому что разработчики достаточно высокого калибра, что трудно оправдать время и ресурсы для написания модульных тестов (не упомянем, что мы используем REAL testers). Серьезно. Написание единичных тестов дало бы нам только минимальное значение, возврат инвестиций не существует. Конечно, это дало бы людям приятное теплое нечеткое чувство: "Я могу спать по ночам, потому что мой код ЗАЩИЩЕН с помощью модульных тестов, и, следовательно, вселенная находится в хорошем равновесии", но на самом деле мы занимаемся написанием программного обеспечения, а не давая менеджерам теплые нечеткие чувства.

Конечно, есть абсолютно веские причины для модульных тестов. Проблема с модульным тестированием и TDD заключается в следующем:

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

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

Ответ 2

Важно понимать, что это не бесплатно. Тесты требуют усилий для написания и, что более важно, поддержания.

Руководители проектов и команды разработчиков должны знать об этом.

Ответ 3

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

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

Итак, чтобы согласиться с другими ответами на ОП: потому что они стоят времени, а стоимость-выгода не показана.

Ответ 4

У вас есть уровень доступа к данным, который нелегко адаптирован для насмешек.

Ответ 5

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

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

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

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

Это не панацея, но это полезная практика.

Ответ 6

Формальная проверка.

Если вы можете формально доказать правильность кода, нет причин для unit test, если только условие теста не введет новые переменные, и в этом случае у вас будет только небольшое количество модульных тестов (или доказать для новых переменных).

Ответ 7

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

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

Ответ 8

Это обычный анализ затрат/выгод.

Стоимость: вам нужно потратить время на разработку и поддержание тестов и направить ресурсы на их работу.

Преимущества хорошо известны (в основном, более дешевое обслуживание/рефакторинг с меньшим количеством ошибок).

Итак, вы балансируете один против другого в контексте проекта.

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

Ответ 9

• Тестирование подобно страхованию.
  • Вы не вкладываете в него все свои деньги.
  • Но вы не избегаете страхования жизни. (Люди из США должны все еще помнить о законопроекте о медицинском страховании).
  • Страхование - ЭССЕНТИАЛЬНОЕ зло.
  • НО НО НО...
    • Вы не застрахованы, ожидая, что смертельная авария вернет все деньги, которые вы вложили в свой страховой план.

Таким образом,

• Существует некоторая причина для написания тестов.
• Единичные тесты иногда являются одним из многих способов продвижения вперед.
• НО НЕТ ПРИЧИНЫ, чтобы просто полностью сосредоточиться на написании (Unit) Tests.

Ответ 10

Недетерминированные результаты.

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

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

Ответ 11

Лень, иногда я ленив и просто не хочу этого делать!

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

Ответ 12

• Это может препятствовать экспериментированию с несколькими вариантами, особенно на ранних этапах проекта. (Но это также может стимулировать эксперименты на более поздних этапах!)

• Он не может заменить тестирование системы, поскольку он не охватывает взаимосвязь между компонентами. Поэтому, если вам нужно разделить время тестирования между тестированием системы и модульным тестированием, то слишком много модульного тестирования может отрицательно повлиять на количество системных тестов.

Я хочу добавить, что я обычно рекомендую модульное тестирование!

Ответ 13

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

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

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

Ответ 14

Я бы не сказал, что это аргумент против этого, но для нас у нас есть унаследованное приложение с TON кода и написано в COBOL. На данный момент практически невозможно сказать, что мы хотим реализовать модульное тестирование и делать это с какой-либо степенью точности или в разумные сроки для бизнеса, как указано duffymo.

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

Ответ 15

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

Вот несколько примеров:

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

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

Существует не менее двух альтернатив модульному тестированию для вышеупомянутых сценариев:

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

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

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

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

Ответ 16

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

Ответ 17

Никогда не бывает причин никогда не писать модульные тесты.

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

* Редактировать

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

Будут ли те вещи нуждаться в модульных тестах?

Ответ 18

Для написания модульных тестов в целом кривая обучения является самой большой причиной, о которой я знаю, чтобы не беспокоиться. Я пытаюсь научиться хорошему модульному тестированию в течение примерно 1,5 лет, и я чувствую, что я просто хорошо разбираюсь в этом (написание шпионов журнала аудита, насмешка, тестирование 1 ограничение на тест и т.д.), Хотя я чувствую, что он ускорило развитие для меня примерно 1 год того времени. Так что назовите это 6 месяцев борьбы через него, прежде чем он действительно начал окупаться. (Я все еще делал "настоящую" работу за это время, конечно.)

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

Для множества конкретных случаев способность unit test может быть заблокирована; другие комментировали некоторые из них.

Ответ 19

Единичное тестирование - это компромисс. Я вижу две проблемы:

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

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

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

Ответ 20

В Test Driven Development модульные тесты на самом деле важнее всего - это способ разработки вашего кода для тестирования. Как выясняется, ваш код имеет тенденцию быть более модульным и писать тесты помогает использовать API и т.д.

Слишком часто, вы обнаруживаете, что разрабатываете код, а затем пишите тесты, комментируя код, который вы только что написали, чтобы убедиться, что тесты терпят неудачу, а затем выборочно удаляют токены комментариев, чтобы пройти тесты. Зачем? Ну, потому что гораздо труднее писать тесты, чем писать код в некоторых случаях. Также часто гораздо сложнее написать код, который можно протестировать полностью автоматическим способом. Подумайте о пользовательских интерфейсах, код, который генерирует изображения или pdf файлы, транзакции базы данных.

Таким образом, модульные тесты очень помогают, но ожидают написать примерно в 3 раза больше кода для тестов, чем вы будете писать для реального кода. Кроме того, все это нужно будет поддерживать. Значительные изменения в приложении будут аннулировать огромные куски тестов - хорошая мера воздействия на систему, но все же... Вы готовы к этому? Вы в небольшой команде, где вы работаете 5 разработчиков? Если это так, то автоматическая разработка TDD просто не будет летать - у вас не будет времени на то, чтобы сделать вещи достаточно быстро. Таким образом, вы в конечном итоге полагаетесь на свое собственное ручное тестирование, тестирование QA, а также просто жить с ошибками, проскальзывающими, а затем фиксировать все как можно скорее. Это печальное, высокое давление и раздражение, но это реальность в небольших компаниях, которые не нанимают достаточно разработчиков для работы, которая должна быть выполнена.

Ответ 21

Нет, на самом деле я этого не делаю. По моему опыту люди, которые делают, представляют аргумент соломенного человека или просто не знают, как unit test вещи, которые не очевидны, как unit test.

@Khorkak. Если вы измените функцию в своем производственном коде, это повлияет только на несколько штучных тестов. Если вы этого не сделаете, это означает, что вы не развязываете свой производственный код и тестирование изолированно, а вместо этого исключаете большие фрагменты вашего производственного кода при интеграции. Это просто плохие навыки тестирования единицы, и да, это БОЛЬШАЯ проблема. Не только потому, что ваша база кода unit test будет трудно поддерживать, но также потому, что ваша производственная кодовая база будет сосать и иметь ту же проблему.

Ответ 22

Единичные тесты не имеют смысла для одноразового кода: если код является доказательством концепции Q & D, то, созданное во время всплеска, чтобы исследовать различные подходы или что-то еще, что вы уверены, почти всегда будет выброшено, тесты не принесут большой отдачи от инвестиций. На самом деле они могут навредить вам, так как время, затраченное на время, не пробовал другой подход и т.д. (Альтернативные затраты)

Ключ уверен, что случай или наличие достаточного понимания с товарищами по команде и т.д., если кто-то скажет "что здорово, используйте тот", который затем вложил время, довести код до стандартов для NON одноразового кода,

Для тех, кто попросил лучшего доказательства, я приведу вас на эту страницу. http://biblio.gdinwiddie.com/biblio/StudiesOfTestDrivenDevelopment обратите внимание, что многие из них являются исследованиями по академическим типам, но сделаны против групп, выполняющих реальную работу по производству программного обеспечения, поэтому лично кажется, что они имеют довольно хорошую достоверность.