Чи допомогли вам генератори тестових пристроїв під час роботи зі застарілим кодом?

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

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

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

Моє запитання: чи використовували ви генератори тестових одиниць раніше, коли розпочали роботу над застарілою базою кодів, і якщо так, чи рекомендували б ви їх?

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

unit-testing legacy

— Дункан Байн
джерело

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

— Док Браун

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

Щоб бути прагматичним, вам слід переглянути всі списки помилок. Потім створіть одиничні тести для кожної з помилок, в результаті чого слід вести себе. В ідеалі ви б додавали новий код для кожної помилки лише під час її отримання.

Часи для додавання одиничного тестового коду:

Додавання нового функціоналу
Код на повторний облік
Виправлена помилка
Дізнатися, що робить код
Доведіть, що помилка існує

Важко оцінити значення додавання одиничних тестів після факту.

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

— Ендрю Т Фіннелл
джерело

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

— Данкан Бейн

+1, зйомка для покриття після факту зазвичай не є продуктивною. Тести на виправлені помилки, що запобігають регресу, дуже продуктивні. Регресія помилки може бути дуже неприємною для всіх, хто бере участь. Тести дійсно підходять для того, щоб допомогти вам написати кращий код. Усунення тестів зазвичай призводить до нестандартних тестів. Я думаю, що ОП побоюється, і співвідношення сигнал / шум від генерованих тестів просто перешкодить. Неперевірений код, ймовірно, має в собі кілька дуже галузевих бітів. Інструменти, які вказують на запах коду, напевно, є більш корисними. Можливо FXCop та подібні інструменти.

— kevpie