Додавання модульних тестів до застарілого коду [закрито]

Ви коли-небудь додавали модульні тести, фактично, до застарілого коду? Наскільки складним був код і наскільки складно все заглушити та знущатись? Чи був вартий кінцевий результат?

Я знайшов найкращий спосіб - це поступово додавати модульні тести, а не просто вскакувати і сказати, що тепер ми будемо модульно тестувати додаток.

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

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

Це не є простим способом.

Це запитання може допомогти з іншими пропозиціями. Як ввести модульне тестування у велику застарілу (C / C ++) кодову базу?

Книга Майкла Пір'я "Ефективна робота зі спадковим кодексом" - ціла книга, що охоплює цю тему. Майкл заявляє, що часто занадто складно вводити тести для застарілого коду, оскільки він не побудований для перевірки. Найбільше з книги я отримав пару шаблонів під назвою "Функції паростків" та "Класи паростків". Функція паростка - це функція, яка інкапсулює зміни, які потрібно внести в код. Потім ви модульно перевіряєте лише ці функції. Клас sprout - це та сама ідея, за винятком того, що нова функціональність міститься в класі.

Так, і це взагалі боляче. Мені часто траплялося писати інтеграційні тести.

У книзі «Мистецтво модульного тестування» є кілька хороших порад щодо цього. Він також рекомендує книгу « Ефективно працювати з кодексом спадщини» ; Я ще не читав останнього, але він у мене в стосі.

EDIT: Але так, навіть мінімальне покриття коду було вартим. Це додало мені впевненості та захисної мережі для рефакторингу коду.

РЕДАГУВАТИ: Я читав "Ефективна робота з застарілим кодом", і це чудово.

Подивіться також на новий підхід у галузі тестування застарілого коду - проект Asis , натхненний проектом ApprovalTests та ділиться ключовими концепціями.

Як уже згадувалося про підхід ApprovalTests у цій статті :

Часто у вас є величезний проект застарілого коду, де у вас взагалі немає тестів, але вам доведеться змінити код, щоб застосувати нову функцію або рефактор. Найцікавіше у застарілому коді - це працює! Це працює роками, як би не писалося. І це дуже велика перевага цього коду. Завдяки схваленням, лише за допомогою одного тесту ви можете отримати всі можливі результати (HTML, XML, JSON, SQL або будь-який інший вихід) і схвалити, бо ви знаєте - це працює! Після того, як ви пройшли такий тест і затвердили результат, ви справді набагато безпечніші за допомогою рефакторингу, оскільки зараз ви «заблокували» всю існуючу поведінку.

Інструмент Asis - це точно збереження застарілого коду шляхом автоматичного створення та запуску тестів характеристик.

Для отримання додаткової інформації див

• детальний README у репозиторії github проектів
• дискусія щодо хакерських новин
• обговорення на reddit.com/r/php
• обговорення на reddit.com/r/programming

Однією з альтернатив модульним тестуванням, яка також представлена ​​в «Ефективна робота зі застарілим кодом», є тести характеристик . У мене були цікаві результати з такими тестами. Їх легше налаштувати, ніж модульні тести, оскільки ви тестуєте з точки, ніж можна перевірити (так званий шов). Недоліком є ​​те, що коли тест не вдається, ви менше натякаєте на місце проблеми, оскільки тестована площа може бути набагато більшою, ніж при модульних тестах. Тут допомагає лісозаготівля.

Структура модульних тестів, така як із сімейства xUnit, може бути використана для написання тестів характеристик.

У таких тестах, написаних після фактів, твердження підтверджують поточну поведінку коду. На відміну від модульних тестів, вони не доводять, що код правильний, вони просто закріплюють (характеризують) поточну поведінку коду.

Процес подібний до TDD:

• написати тест на частину коду
• виконати його - не вдалося
• виправити тест за спостережуваною поведінкою коду
• виконати його - пройти
• повторити

Тести не пройдуть, якщо ви зміните зовнішню поведінку коду. Зовнішня поведінка коду? звучить знайомо? Так, ось ми тут. Тепер ви можете переробляти код.

Очевидно, що ризик залежить від охоплення характеристичними тестами.

Погляньте на безкоштовну утиліту з відкритим кодом для тестування модулів ApprovalTests . Якщо ви розробник .NET, творець Llewellyn Falco створив серію відео, на яких показано, як він використовує ApprovalTests для вдосконалення модульного тестування як для нового, так і для застарілого коду.

Якщо ви плануєте рефакторинг застарілого коду, тоді створення цих модульних тестів є обов’язковим. Не турбуйтеся про глузування чи заглушення - турбуйтеся про тестування входів і виходів системи, щоб ваші зміни чи зусилля з рефакторингу не порушили поточну функціональність.

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

Я говорив деякий час тому про ідею піраміди зворотних тестів у застарілому коді на XPDays http://xpdays.com.ua/archive/xp-days-ukraine-2012/materials/legacy-code/

Ця презентація повинна дати відповідь на запитання, чому так важливо іноді починати з інтеграційних / функціональних або навіть високоприйнятних тестів при роботі зі застарілим кодом. А потім повільно, поетапно вводячи модульні тести. Прикладів коду немає - вибачте, але купу з них ви можете знайти в книзі Майклза Пір’я "Ефективна робота зі застарілим кодом".

Також ви можете перевірити відступ від застарілого коду http://www.jbrains.ca/legacy-code-retreat та шукати цю зустріч у вашому районі.