Действительно ли Поблочное тестирование стоит усилия в большом и старом (5 лет) кодовая база?
Я только что присоединился к команде, которая работала в основном всегда режиме в течение прошлых 5 лет (Java, основанный на знатоке проект). Следовательно, планы усилить поблочное тестирование всегда готовились, никогда не осуществляясь (до сих пор). Великая команда разработчиков гарантировала, что качество кода обычно хорошо, и нет структурных проблем кода, но нет только никакой культуры записи jnuit тестов. Но я, видя преимущества поблочного тестирования, являюсь одиноким воином, здесь стремящимся к принятию автотестирования.
Расположение команды таково, что отдельная команда тестирования делает ручное тестирование функциональности перед развертыванием кода, и команда управления изменениями является checkgate для одобрений изменения и сборок (никакая непрерывная интеграция также, до сих пор).
Следующее является препятствиями: Поскольку кодовая база огромна, и некоторые исходные разработчики оставили команду, любые дополнительные модульные тесты могут быть слишком мало, слишком поздно. Добавьте к нему, что я могу быть единственным, стремящимся к поблочному тестированию. Хотя мой менеджер поддержал идею, он не хочет, чтобы команда изменения была сорвана к дополнительному времени, требуемому, чтобы тесты работали.
Я имею мнение, что автономный инструмент CI может использоваться для начинаний с, и команда изменения должна изменить их сценарии для пропуска тестов, как и когда они добавляются.
Что Вы сделали бы в моей обуви?
P.S.: я знаю о подобном вопросе на stackoverflow, но в этом, цель состоит в том, чтобы убедить различные заинтересованные стороны и лучший путь к takel; не технологическое сравнение.
5 ответов
Похоже, вы довольно хорошо разбираетесь в ситуации.
Две вещи:
Не надейтесь, что сможете полностью провести модульное тестирование проекта 5-летней давности. Если предположить, что 5 разработчиков проработают 5 лет, то получится около 50 000 часов программиста. Если предположить, что на написание тестов уходит столько же времени, сколько на код, у вас будет неплохо получить 2-3% покрытия в год.
Итак: Протестируйте новый код и напишите тесты для модификаций старого кода. Найдите время / потратьте время на настройку какого-либо типа CI. Постепенно вы накопите хороший набор тестов.
Поскольку вы, очевидно, не тонете в ошибках, начинайте медленно, набирайте обороты.
Было бы целесообразно написать тесты для проверки конкретных функций, над которыми вы работаете и хотите оставаться стабильными.
Имея большое существующее приложение, которое в настоящее время не имеет покрытия тестами, вам не захочется сесть и написать тесты за один раз, чтобы получить 100% покрытие модульным тестом, и вы никогда этого не сделаете. Вы просто выделяете конкретный функционал для тестирования. Я не думаю, что есть такие вещи, как слишком мало или слишком поздно; Модульные тесты только для крошечной части очень важной функциональности лучше, чем вообще ничего, а некоторые модульные тесты сейчас лучше, чем никакие модульные тесты когда-либо.
Модульное тестирование выгодно даже в старом проекте, например, установив модульные тесты, вы можете быть уверены, что проблема не в существующем коде, а в новом коде (даже если у вас есть процесс QA, ошибки все равно появляются в отдельных случаях). Кроме того, они предотвращают появление тонких различий в поведении при изменении старого кода. Кроме того, модульные тесты документируют предполагаемое поведение огромной кодовой базы.
Внедрение крупных изменений никогда не бывает легким. Первый и самый простой способ - это обязательное модульное тестирование всего нового кода, чтобы не накапливать объемы усилий и нагрузки, связанные с модульным тестированием старой кодовой базы. Затем вторая часть - проявить инициативу и создать несколько модульных тестов для старого кода. Если вы это сделаете, то сможете убедить других членов вашей команды помочь в создании модульных тестов для существующего кода. При необходимости придумайте забавные стимулы, например пообещайте пиццу для команды, которая создаст наибольшее количество модульных тестов для существующей базы кода.
Также напомните своим товарищам по команде, что это не то место, где им нужно отказываться от всего, что они делают ... если они создают только один модульный тест для существующего компонента каждый день поверх своей другой работы, тогда в конечном итоге вы получит модульный тест для всех существующих компонентов в вашей кодовой базе.
ИМХО, модульные тесты или любые другие тесты (за исключением функциональных) должны часто выполняться на критических и волатильных частях приложения одновременно. Другими словами, модульные тесты должны писаться не ради написания тестов, а для того, чтобы инженеры по разработке/обслуживанию не споткнулись об определенные условия в коде.
Учитывая это, вы также можете обратить внимание на интеграционные тесты, которые выполняются на CI-сервере, в большей степени потому, что они ближе к функциональным тестам, а также потому, что код является зрелым. По моим наблюдениям, найти модульные тесты для написания в зрелом приложении гораздо сложнее, и в краткосрочной перспективе они имеют меньший RoI, чем интеграционные тесты.
Интеграционные тесты в вашем случае будут гарантировать, что различные уровни приложения продолжают удерживаться вместе в соответствии с намерениями первоначальных разработчиков. С другой стороны, юнит-тесты, будучи немного более локализованными по своей природе, будут гарантировать, что любой новый патч/исправление ошибки в определенной области вызовет побочные эффекты в этой области.
Это потребует огромных усилий, а отдача будет небольшой. Лучше автоматизируйте и расширьте текущее тестирование для обеспечения стабильности системы (я предполагаю, что на системном уровне уже есть некоторое тестирование). Я думаю, вам следует сосредоточиться на тех частях системы, которые все еще подвергаются большим изменениям или которые вы планируете изменить в ближайшем будущем.
Юнит-тестирование - это хорошо, но его может быть трудно внедрить в существующую систему. Если вы сосредоточитесь только на модульном тестировании в течение следующего года или более, вы потеряете динамику развития".