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

Я смотрю на небольшую (~ 70kLOC, включая сгенерированную) C # (.NET 4.0, немного Silverlight) кодовую базу, которая имеет очень низкий охват тестированием. Сам код работает в том смысле, что он прошел пользовательское приемочное тестирование, но он хрупкий и в некоторых областях не очень хорошо продуман. Я хотел бы добавить твердое покрытие модульных тестов для устаревшего кода, используя обычные подозрения (NMock, NUnit, StatLight для битов Silverlight).

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

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

Мой вопрос: использовали ли вы генераторы модульных тестов в прошлом, когда начинали работу над устаревшей кодовой базой, и если да, то порекомендуете ли вы их?

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

unit-testing legacy

— Дункан Бэйн
источник

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

— Док Браун

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

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

Время добавить код модульного теста:

Добавление нового функционала
Рефакторинг кода
Исправлена ошибка
Изучение того, что делает код
Докажите, что ошибка существует

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

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

— Эндрю Т Финнелл
источник

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

— Дункан Бэйн

+1, Съемка для освещения по факту обычно не продуктивна. Наличие тестов на исправленные ошибки, которые предотвращают регрессию, очень продуктивно. Регрессирование ошибки может быть очень неприятным для всех участников. Тесты действительно подходят для того, чтобы помочь вам написать лучший код. Болтовые испытания обычно приводят к некачественным испытаниям. Я думаю, что опасения ОП основаны, и отношение сигнал / шум от сгенерированных тестов будет только мешать. В непроверенном коде, вероятно, есть некоторые очень разветвленные биты. Инструменты, которые указывают на запахи кода, вероятно, более полезны. Возможно FXCop и подобные инструменты.

— kevpie