Какие-либо хорошие аргументы для того, чтобы не записать модульные тесты? [закрытый]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

*Edit

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

Нужны ли этим вещам юнит-тесты?

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

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

Хочу добавить, что я обычно поощряю модульное тестирование!

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

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

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

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

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

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

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

Подводя итог,

• Есть некоторые причины для написания тестов.
• Юнит-тесты иногда являются одним из многих способов продвижения вперед
• НО НЕТ НИКАКОЙ ПРИЧИНЫ, чтобы полностью сосредоточиться на написании (юнит) тестов.

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

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

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

Формальная верификация.

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

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

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

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

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

Вот некоторые примеры:

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

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

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

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

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

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

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

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

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

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

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

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