За и против поблочного тестирования после факта

Вот некоторые из них, на мой взгляд:

Pro:

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

Против:

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

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

Pro постфактум модульное тестирование:

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

Con постфактум модульное тестирование:

• Пустая трата времени исправление ошибок, с которыми вы можете жить . (Если вы написали 27KLOC, мы надеемся, что он что-то дает, верно?)
• Потратьте время на понимание и рефакторинг кода, который вам не нужно понимать.
• Потратьте время на следующий проект.

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

Модульное тестирование «постфактум» по-прежнему ценно и обеспечивает большинство тех же преимуществ модульного тестирования во время разработки.

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

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

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

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

Я считаю, что модульное тестирование существующего кода дает несколько преимуществ

• Управление регрессией
• Лучшее понимание кода. Его тестирование выявит случаи, которых вы не ожидали, и поможет определить поведение кода
• . Это укажет на недостатки конструкции в коде, когда вы будете пытаться тестировать плохо определенные методы.

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

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

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

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

Модульное тестирование не доказывает, что система работает. Это доказывает, что каждая единица работает как независимая единица.Это не доказывает, что интегрированная система будет работать

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

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

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

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

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

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

Помимо этого, есть несколько других важных преимуществ модульного тестирования,

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

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

Модульное тестирование по-прежнему полезно. Ознакомьтесь с http://en.wikipedia.org/wiki/Unit_testing для получения полного списка и объяснения преимуществ.

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

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

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