Надійний комплексний набір тестів значно спрощує рефакторинг коду. Але що робити, коли таких тестів було проведено мало, чи вони не виконувались взагалі?
Що таке рефакторинг?
Якщо узагальнити, під рефакторингом розуміють реорганізацію коду зміни його поведінки. Тобто, ми ставимо в основу поведінку: нам потрібно гарантувати, що, виконуючи рефакторинг, ми його не змінимо.
Як це можна забезпечити? Відповідь проста: тести. Саме тести підтверджують, що наша система чи компонент поводиться так, як очікувалося, за заданих умов. За наявності тестів процес рефакторингу істотно спрощується, оскільки у нас є засіб перевірки (валідації). Але код, добре покритий тестами - це ідеальний випадок, і насправді зустрічається рідко. Давайте поглянемо на випадок складніший і реалістичніший.
Жах кошмар на ім'я «Legacy-проекти»
Розглянемо якийсь сценарій із життя рядового (чи не дуже) програміста. Уявіть, що менеджер кидає вас на проект із legacy-кодом (тобто, успадкованим, не дуже новим і найчастіше – дуже заплутаним кодом). Ніхто не в курсі, як цей код працює, документації катастрофічно не вистачає, а ту, що є, писав невідомий непрямий іноземець, який побажав залишитися невідомим.
Що тепер робити? Не звільнятися ж, зрештою! Хоча після пари-трійки годин копання в нетрях legacy, цей варіант здасться вам привабливим. Але здаватися зарано! Насправді, все, що від нас вимагається – забезпечити незмінність поведінки. В умовах нестачі інформації це завдання нетривіальне. З чого почати? Писати випробування. Тести, тести, і ще раз тести.
Крок 1. «Димові» тести
Перший тип тестів, яким ми скористаємося, – це звані «димові» тести (англ. smoke testing). Під цим терміном розуміють мінімальний набір тестів на помилки. "Димовий" тест зазвичай виконується самим програмістом. Програму, що не проходила цей тест, не має сенсу віддавати на більш глибоке тестування. «Димові» тести відмінно підходять для демонстрації того, що найважливіша частина системи веде себе адекватно та передбачувано. Тобто ми додаємо "димові" тести до нашого конвеєра розгортання (створіть його, якщо ще не створабо) на кроці перевірки складання. Після виконання "димових" тестів ми можемо бути впевнені, що нічого не порушабо критично. Крім того, на додачу до цього чудового ефекту ми отримуємо знання: після створення "димових" тестів, ми починаємо набагато краще розуміти систему.
Крок 2. Модульне тестування
Наша наступна стратегія – модульне тестування. Модульне або юніт-тестування (англ. unit testing) - процес у програмуванні, що дозволяє перевірити на коректність окремі модулі вихідного коду програми. Ідея полягає в тому, щоб писати тести для кожної нетривіальної функції чи методу. Цей підхід використовується у Java-програмуванні повсюдно. Реалізація модульного тестування – набагато складніше завдання. Цей процес має бути покроковим. Неможливо написати модульні тести для кожного компонента, та й сенсу в цьому особливого немає, оскільки вам все одно незабаром буде рефакторинг. Отже, потрібно переконатися, що хоча б основні компоненти поводяться як належить. Отже, виберіть один із основних компонентів та почніть його тестувати. Написання модульних тестів автоматично призведе до невеликого рефакторингу успадкованого коду. До того ж, ви почнете розуміти внутрішній пристрій проекту набагато краще.
Підсумки
Після реалізації цих стратегій, у вас не залишиться не протестованого коду, і туман легаси-коду стане набагато менш щільним. Зрозуміло, що в команді може знайтися людина, яка скаже, що на тестування немає часу. Постарайтеся переконати його, що навпаки, відмова від тестування призведе до набагато більших тимчасових втрат у довгостроковій перспективі. А, отже, слід зробити тестування найпершим і найбільш пріоритетним завданням, перш ніж приступати до будь-якого серйозного рефакторингу. Якщо вас відмовляють від тестування - сперечайтеся, відстоюйте свою думку. Інакше вся команда зазнає невдачі. Якщо уникнути зустрічі з успадкованим кодом неможливо, перш ніж розпочинати рефакторинг, протестуйте його. Кращої стратегії просто не існує. Відмова від тестування – запорука майбутньої поразки.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ