Имеет ли смысл добавлять модульные тесты для хорошо известного устаревшего кода?

• Я говорю о модульных тестах в смысле TDD. (Не автоматизированная «интеграция», или то, что вы любите называть тестами.)
• Устаревший код как в: (C ++) код без тестов. (см .: « Эффективная работа Майкла Фезерса с устаревшим кодексом» )
• Но также унаследованный код, такой как: Код, с которым наша команда работала последние 10-5 лет, поэтому мы очень часто имеем хорошее представление о том, где что-то изменить.
• У нас есть модульные тесты (через Boost.Test) для некоторых модулей, которые пришли позже или были «естественными» для модульных тестов (общие контейнеры для конкретных приложений, строковые вещи, сетевые помощники и т. Д.)
• У нас пока нет надлежащих автоматических приемочных испытаний.

Недавно у меня было «удовольствие» реализовать 3 новые функции, ориентированные на пользователя.

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

Теперь я действительно добавил немного кода. (Я думаю, один метод и несколько линий вызова для каждой функции.)

Извлечение этого кода (с помощью любого из методов, предложенных в WEwLC ), чтобы модульный тест имел смысл (а не полную тавтологию), легко занял бы еще 2-4 часа, если не больше. Это добавило бы 50% -100% времени к каждой функции, без немедленной выгоды, так как

1. Мне не нужен юнит-тест, чтобы понять что-нибудь о коде
2. Ручное тестирование - это тот же объем работы, который мне все еще нужно проверить, правильно ли код интегрирован в остальную часть приложения.

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

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

Это что-то типичное для сильно связанного унаследованного кода? Я ленивый / мы устанавливаем неправильные приоритеты как команда? Или я осторожен, только проверяю вещи, где накладные расходы не слишком высоки?

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, для написания модульных тестов может потребоваться еще 2-3 часа, но если код будет возвращен из тестирования, вам придется снова все вручную проверить и снова задокументировать свое тестирование - вы делаете это, не так ли? Иначе как кто-нибудь узнает, что вы тестировали и какие значения использовали?

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

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

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

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

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

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