За и против модульного тестирования после факта

Question

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

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

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

Что скажете вы.

Answer 1

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

• Регрессионный менеджмент
• Лучшее понимание кода. Тестирование выявит случаи, которые вы не ожидали, и поможет определить поведение кода
• Он укажет на недостатки проекта в коде, когда вы пытаетесь протестировать плохо определенные методы.

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

Answer 2

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

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

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

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

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

Answer 3

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

(Это не значит, что писать модульные тесты - плохая идея, просто TDD почти всегда лучшая идея .)

Answer 4

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

Pro:

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

Con:

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

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

Answer 5

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

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

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

Answer 6

Pro post facto модульное тестирование:

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

Con post facto модульное тестирование:

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

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

Answer 7

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

Answer 8

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

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

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

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

Answer 9

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

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

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

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

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

Answer 10

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

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

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