Основна проблема застарілого коду полягає в тому, що він не має тестів. Тож вам потрібно додати трохи (а потім більше ...).
Це само по собі зайняло б багато роботи, як зазначав @mattnz. Але особливою проблемою застарілого коду є те, що він ніколи не був розроблений для перевірки . Тому зазвичай це величезна суперечливість коду спагетті, де дуже важко або прямо неможливо виділити дрібні деталі, які підлягають випробуванню. Тому перед тестуванням одиниці потрібно перефактурувати код, щоб зробити його більш зрозумілим.
Однак, щоб безпечно переробити фактор, ви повинні провести одиничні тести, щоб переконатися, що ви нічого не порушили зі своїми змінами ... Це привід 22 застарілого коду.
Книга вчить, як вийти з цього улову, вносячи абсолютні мінімальні, найбезпечніші зміни в коді лише для того, щоб увімкнути тести першого блоку. Вони не призначені для того, щоб зробити дизайн приємнішим - лише для того, щоб увімкнути одиничні тести. Насправді іноді вони роблять дизайн більш потворним або складнішим. Однак вони дозволяють писати тести - і, як тільки ви встановите одиничні тести, ви можете зробити дизайн краще.
Існує маса хитрощів, щоб зробити код перевіряючим - деякі начебто очевидні, а інші - зовсім. Є методи, про які б я ніколи не думав про себе, не читаючи книги. Але що ще важливіше, це те, що Пір'я пояснює, що саме робить блок коду перевірити. Вам потрібно скоротити залежності та ввести бар'єри у свій код, але з двох різних причин:
- зондування - з метою перевірки та перевірки наслідків виконання фрагмента коду та
- розділення - для того, щоб насамперед конкретний фрагмент коду потрапити до тестового джгута.
Вирізати залежності безпечно може бути складним. Представлення інтерфейсів, макетів та залежних ін'єкцій є чистою та приємною метою, просто не обов'язково безпечною для цього. Тому іноді доводиться вдаватися до підкласи випробовуваного класу, щоб перекрити якийсь метод, який, як правило, наприклад, запустив прямий запит до БД. В іншому випадку нам може знадобитися навіть замінити клас залежності / банку на підроблений у тестовому середовищі ...
Для мене найважливіша концепція, яку принесли Пір'я, - це шви . Шов - це місце в коді, де ви можете змінити поведінку своєї програми, не змінюючи сам код . Побудова швів у вашому коді дозволяє відокремити фрагмент коду, що перевіряється, але він також дозволяє відчути поведінку тестового коду, навіть якщо це важко або неможливо зробити безпосередньо (наприклад, через те, що виклик вносить зміни в інший об'єкт або підсистему , стан якого неможливо запитувати безпосередньо з методу тестування).
Ці знання дозволяють помітити насіння доказовості у найгустішій купі коду та знайти мінімальні, найменш руйнівні, найбезпечніші зміни, щоб потрапити туди. Іншими словами, щоб уникнути «очевидні» рефакторінга , які мають ризик злому коду без вас помітити , - тому що ви не ще є юніт - тести , щоб визначити , що.