Можно ли успешно добавить модульное тестирование в существующий производственный проект?Если да, то как и стоит ли это того?

Question

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

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

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

Так что я думаю, что я тоже спрашиваю;

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

(Очевидно, что ответ на третий пункт полностью зависит от того, говорите ли вы с руководством или разработчиком)

---

Причина получения награды

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

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

Answer 1

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

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

Стоит ли усилий для существующего Решение, которое находится в производстве?

Да. Вы увидите эффект появления ошибок и упрощения обслуживания

Было бы лучше проигнорировать тестирование для этого проекта и добавить его в возможное будущее переписать?

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

Что будет более полезным; расходы несколько недель, добавляя тесты или несколько недель добавляется функциональность?

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

Answer 2

Обновление

Через 6 лет после первоначального ответа у меня немного другое мнение.

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

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

Предыдущий ответ

Я собираюсь поднять несколько бровей здесь:)

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

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

Почему?

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

2. Модульные тесты стоят времени!Теперь, откуда я родом, это ценный товар - и бизнес обычно выбирает лучшую функциональность по сравнению с полным набором тестов.

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

4. Модульные тесты не повлияют на воспринимаемое качество вашего продукта - качество, которое видит пользователь.Конечно, ваши методы могут работать точно так же, как в первый день, интерфейс между уровнем представления и уровнем бизнеса может быть нетронутым - но угадайте, что?Пользователю все равно!Получить реальных тестеров, чтобы проверить ваше приложение.И чаще всего эти методы и интерфейсы рано или поздно должны измениться.

Что будет более полезным;потратить несколько недель на добавление тестов или несколько недель на добавление функциональности?- Есть чертовски много вещей, которые вы можете сделать лучше, чем писать тесты - Написать новую функциональность, улучшить производительность, улучшить удобство использования, написать лучшие справочные руководства, устранить ожидающие ошибки и т. Д. И т. Д.Если вы абсолютно уверены, что в ближайшие 100 лет ситуация не изменится, продолжайте, вырубитесь и напишите эти тесты.Автоматические тесты - отличная идея и для API, где вы абсолютно не хотите нарушать сторонний код.В другом месте, это просто то, что заставляет меня отправлять позже!

Answer 3

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

Answer 4

Стоит ли усилий для существующего решения, которое находится в производстве?

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

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

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

Что будет более полезным;потратить несколько недель на добавление тестов или несколько недель на добавление функциональности?

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

Answer 5

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

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

Answer 6

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

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

Для новых функций я бы придерживалсяподход извне: начните с функций, документированных в RSpec и проверенных путем автоматизации пользовательского интерфейса (который, конечно, изначально потерпит неудачу), затем добавьте более детальные модульные тесты по мере реализации.

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

Answer 7

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

• Как вы упоминали, когда вы находите ошибку, самое время написатьтест (чтобы воспроизвести его), а затем исправить ошибку.Если вы видите, что тест воспроизводит ошибку, вы можете быть уверены, что это хороший тест alid.Учитывая, что большая часть ошибок является регрессией (50%?), Почти всегда стоит писать регрессионные тесты.
• Когда вы углубляетесь в область кода, чтобы изменить ее, самое время написать тесты вокруг нее.,В зависимости от характера кода подходят различные тесты.Один хороший набор советов можно найти здесь .

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

Удачи!

Answer 8

Я предлагаю прочитать блестящую статью инженера TopTal, которая объясняет где , чтобы начать добавлять тесты: в ней много математики, но основная идея:

1) Измерьте Afferent Coupling (CA) вашего кода (насколько класс используется другими классами, то есть нарушение его приведет к серьезному повреждению)

2) Измерьте код вашего Цикломатическая сложность (CC) (более высокая сложность = более высокая степень изменения разрывности)

Вам необходимо идентифицировать классы с высоким CA и CC, т.е. иметь функцию f (CACC) и классы с наименьшими различиями между двумя метриками должны иметь наивысший приоритет для покрытия тестами.

Почему?Потому что высокие CA, но очень низкие классы CC очень важны, но вряд ли сломаются.С другой стороны, низкая CA, но высокая CC, вероятно, сломаются, но нанесут меньше урона.Итак, вы хотите сбалансировать.

Answer 9

Вы говорите, что не хотите покупать другую книгу. Так что просто прочитайте статью Майкла Фезера о эффективной работе с устаревшим кодом . Тогда купи книгу:)

Answer 10

Хороших ответов так много, что я не буду повторять их содержание.Я проверил ваш профиль и, кажется, вы разработчик C # .NET.По этой причине я добавляю ссылку на проект Microsoft PEX и Moles , который может помочь вам с автоматическим созданием модульных тестов для унаследованного кода.Я знаю, что автогенерация - не лучший способ, но, по крайней мере, это способ начать.Посмотрите эту очень интересную статью из журнала MSDN об использовании PEX для устаревшего кода .