Написання модульних тестів за допомогою PHPUnit, частина 2: The Tear Down
Наприкінці минулого місяця я почав говорити про написання модульних тестів у PHPUnit для коду на основі WordPress. В першу чергу це включало ідею налаштування PHPUnit, функції setUp і написання основних тестів.
Однак це не обговорювало те, що я знаю про функцію tearDown, яка все ще є важливою особливістю написання за допомогою тестів. Крім того, є два способи написання тестів для проектів WordPress.
а саме:
- написання тестів спеціально для плагінів і функцій прикладного рівня,
- виконання модульних тестів програми WordPress.
Перш ніж рухатися далі з цією конкретною публікацією, я рекомендую надолужити те, що я розглянув досі. Це включає такі публікації:
- Середовище розробки WordPress (з використанням менеджера пакетів)
- IDE для розробки WordPress
- Робота з налаштуваннями користувача в Visual Studio Code
- Написання модульних тестів за допомогою PHPUnit, частина 1: налаштування
Коли ви це зробите, поверніться до цієї публікації та продовжимо обговорення функції tearDown і того, як насправді виглядають модульні тести в контексті WordPress.
Модульні тести з PHPUnit, Частина 2: Зрив
Перш ніж рухатися вперед, пам’ятайте, що розробники часто розглядають функцію setUp як конструктор, а функцію tearDown як деструктор; однак пам’ятайте, що останній не завжди потрібен.
Ось гарне емпіричне правило, яке слід пам’ятати:
- Все, що потрібно тестовій функції, викличе функцію setUp, щоб потрібні були необхідні класи.
- Функція tearDown не завжди потрібна, оскільки функція setUp може повторно ініціалізувати клас.
Отже, що це означає для функції tearDown, якщо вона не скидає дані, створені під час функції SetUp?
1 Функція розриву
Найкраща порада, яку я можу дати щодо функції tearDown, полягає в тому, що її слід використовувати, якщо щось налаштовано під час одного з тестів, що залишилося позаду.
Це може бути щось, що записується в базу даних, щось, що записується в журнал, або, загалом, щось, що записується на жорсткий диск.
Таким чином, якщо тест записує запис або файл, метод tearDown запуститься після тесту та має видалити будь-який тест, записаний на диску, який не є частиною тесту, але не є постійно потрібним для наступного тесту або слід прибрати за собою.
Тож у певному сенсі це як деструктор, але якщо ви ніколи не користувалися мовою, яка має деструктор, ця номенклатура або здається нерелевантною, або не має сенсу.
Деструктор — це спеціальна функція-член, яка викликається, коли закінчується час життя об’єкта. Метою деструктора є звільнення ресурсів, які об’єкт міг отримати протягом свого життя.
Таким чином, можливо, краще просто думати про функцію як про спосіб очищення після тесту (а не в сенсі встановлення змінної, яка дорівнює нулю, оскільки функція setUp може це зробити).
2 модульні тести для проектів WordPress
Пишучи модульні тести для проектів WordPress, ми повинні чітко визначити тип модульних тестів, про які ми говоримо.
Наприклад, те, що я буду називати класичними або стандартними модульними тестами, слідує методології «розробки, керованої тестуванням», про яку я поговорю трохи пізніше. З іншого боку, WordPress має власний набір модульних тестів для тем тощо, про які я також розповім трохи пізніше в цій публікації.
Але для цього розділу я подумав, що було б корисно поговорити трохи про перше, а не про останнє, щоб ви могли побачити, як це може працювати.
У наведеному нижче прикладі я пишу тести для плагіна, який відповідає за зв’язок із стороннім API. Для цього конкретного плагіна потрібні ім’я користувача та пароль або API , і ми хочемо переконатися, що для цілей цієї публікації він належним чином отримує помилку під час кожного запуску тесту.
Зауважте, що читаючи цей код, ви побачите, що я трохи розповідаю про рефлексію. Незабаром я збираюся опублікувати повний пост про PHP Reflection, щоб пролити світло на це.
Однак для наведеного нижче коду припустимо, що це спосіб, за допомогою якого ми можемо отримати доступ до властивостей, які інакше позначені як приватні.
Нагадаємо, з останньої публікації цієї серії у нас був початковий тест, який виглядав так:
Однак зауважте, що в цьому тесті немає функції tearDown, що має сенс, чи не так? Зрештою, нічого не записується в базу даних або файл.
Але, скажімо, ми хочемо представити тестовий приклад, який матиме ім’я файлу, вміст і записуватиме вміст у файл. У цьому випадку це будуть статичні дані, але технічно це може бути все, що записано на диск.
1 Налаштування тесту
По- перше, ми хочемо налаштувати тест, визначивши назву файлу, вміст файлу та підготувавши властивості.
Досить легко, чи не так?
2 Запис і читання даних
Далі ми хочемо записати дані, прочитати дані та підтвердити, що вміст однаковий.
На цьому етапі, якщо ви запустите тест (який я ще не описав технічно, як це зробити), ви помітите, що testFile.txt все ще знаходиться у вашій системі.
3 Використання tearDown
Нарешті, нам потрібно попрацювати з методом tearDown, щоб переконатися, що файл буде видалено після завершення модульного тесту. Ось як це може виглядати, якщо ви реалізували свій код так, як ви бачите вище.
Зверніть увагу, що в методі tearDown я спочатку перевіряю, чи існує file_exists. Це пояснюється тим, що якщо ви просто спробуєте від’єднати файл, якого немає, ви отримаєте повідомлення про помилку під час виконання тестів, тому що, якщо присутній tearDown, він намагатиметься видалити щось після кожної окремої тестової функції. І якщо файл не існує, то його нема чого видаляти, і це призведе до проблеми.
Тому, намагаючись написати код із захистом, я вважаю, що він відповідає за перевірку існування файлу перед фактичною спробою його видалення.
3 Порядок роботи
Коли мова заходить про чисте модульне тестування, ви зазвичай читаєте це з точки зору розробки, керованої тестуванням. Це велика тема сама по собі; однак варто згадати про це, якщо ви вирішите продовжити дослідження та навіть застосувати це у своїх зусиллях щодо розробки.
Загальну ідею цього підходу часто називають «червоно-зеленим повторенням». І я не заперечую цього, щось у цьому підході є. Зокрема, це дозволяє вам, як розробнику, написати код так, як ви очікуєте, що він буде працювати, перш ніж фактично писати код.
Психологія цього полягає в наступному: якщо ви знаєте, як працює код, ви, швидше за все, напишете тести, які пройдуть; тоді як, якщо ви пишете тести для того, як повинен працювати код, ви повинні писати кращий код.
На жаль, ми не завжди можемо дозволити собі таку розкіш. Але це не означає, що ми повинні викидати прославлену дитину разом з водою. Натомість я вважаю, що ви повинні писати тести, коли можете, а потім писати код; інакше пишіть свої тести після коду.
Зрештою, наявність тестування в будь-якому випадку буде кращою, ніж відсутність тестів взагалі.
4 Тестування за допомогою WordPress
Коли справа доходить до модульного тестування в WordPress, є кілька речей, на які ви, ймовірно, натрапили. Іноді вміст є неправильним або навіть може вводити в оману з точки зору «модульного тестування в WordPress».
У цьому випадку варто звернути увагу на дві речі:
- Тематичний модульний тест. Цей окремий набір вмісту призначений для того, щоб допомогти розробникам тем протестувати всі основні та другорядні випадки для своїх тем. Наприклад, немає автоматизованих інструментів, якими ви б користувалися, як у тому, що ми обговорювали вище.
- Автоматизоване тестування. WordPress постачається з власним набором модульних тестів, тому нам не потрібно писати тести для більшості функцій WordPress (наприклад, чи працюють функції API належним чином). Це дозволяє нам зосередитися на написанні модульних тестів для нашої власної доменної логіки.
- Модульні тести плагінів. Якщо ви використовували WP-CLI (або зацікавлені в ньому), то, ймовірно, ви читали цю сторінку або навіть користувалися цим інструментом. Це корисно, але також націлено на певні аспекти тестування плагінів WordPress.
Усе вищезазначене є корисною інформацією, і я не кажу, що її слід ігнорувати. Натомість її слід поєднати з рештою інформації, яка використовується в цій публікації.
Виконання модульних тестів
У наступній публікації я розповім вам усе, що вам потрібно знати, щоб налаштувати XML-файл, який повідомлятиме PHPUnit про те, де знаходяться тести та як їх запускати.
Однак наразі перегляньте код, який міститься в цій публікації, і підготуйтеся до створення на його основі в наступній публікації цієї серії.