Написання модульних тестів за допомогою PHPUnit, частина 1: налаштування

Останнє оновлення Лис 26, 2022

Зміст

Модульні тести з PHPUnit, частина 1: налаштування

На початку цього місяця ми почали розглядати встановлення PHPUnit у Visual Studio Code з кінцевою метою навчитися писати модульні тести для наших проектів на основі WordPress.

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

І, звичайно, встановлення PHPUnit у Visual Studio Code, як зазначено вище. Коли це буде зроблено, ми будемо готові продовжити. Але пам’ятайте, що цей вечір буде традиційним або комплексним курсом написання модульних тестів.

Замість цього все зводиться до написання модульних тестів для проектів WordPress.

Модульні тести з PHPUnit, частина 1: налаштування

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

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

1 Написання модульних тестів

Щоразу, коли ви вперше починаєте писати модульні тести, вам буде представлено як ідею методів setUp, так і tearDown. Це часто зустрічається в PHPUnit (як і в інших платформах тестування). У цих двох конкретних методах є кілька речей, які часто викликають проблеми.

Коротше кажучи, люди ставляться до функцій так:

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

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

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

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

2 Функція налаштування

Незважаючи на те, що я починаю з короткого обговорення методу setUp, важливо мати на увазі, що його дочірня функція (як дехто вважає) не завжди потрібна.

Наприклад, якщо ви пишете код, де все, що ви робите, це створення екземпляра об’єкта або набору об’єктів, тоді метод tearDown може не знадобитися. Я детальніше розповім про це в наступному розділі.

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

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

Зрозуміло, можливо, ці дані жорстко закодовані, але для прикладу припустімо інше. Це означає наступне:

У нас є клас, який служить нашим кешем,
Клас підтримує частину даних екземпляра про те, як довго має бути встановлений кеш,
Час кешу можна встановити зі сторонніх класів,
Час кешу можна прочитати зі сторонніх класів.

Це означає, що модульний тест включатиме:

Налаштування класу,
Визначення значення,
Стверджуючи, що визначене значення відповідає очікуванням,
Зміна значення,
Затвердження зміненого значення оновлено.

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

Зауважте, що за замовчуванням час кешу встановлено на 12 годин (у секундах). Клас підтримує можливість як змінювати, так і читати тривалість.

Це означає, що ми можемо писати тести, які перевіряють:

якщо початкове значення відповідає очікуванням,
якщо нове значення відповідає очікуванням (і воно перезаписує початкове значення)

Одна з речей, яку я хотів би відзначити у наведеному вище коді, полягає в тому, що ви можете прочитати, що кожен тест повинен мати одне твердження, тоді як testNewDuration явно має два твердження.

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

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

Як бачите, це не має нічого спільного з WordPress; однак це має відношення до логіки тестування, пов’язаної саме з даним доменом. А саме тривалість кешу. І ось у чому суть модульного тестування: тестування логічної поведінки одиниць коду, щоб переконатися, що все працює належним чином.

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

Виконання тестів

Коли тести написані, важливо вміти їх виконувати, щоб побачити, чи проходять вони, чи не проходять, що проходить, а що ні. Але ми ще не закінчили. Я хочу надати комплексний погляд на модульне тестування в контексті WordPress, і це пов’язано з обговоренням того, що WordPress надає, а чого ні, деякі неправильні уявлення та те, як запускати ці тести в терміналі або в коді Visual Studio.

У наступному дописі з цієї серії ми розглянемо функцію tearDown і як (і коли) її використовувати, коли вона потрібна, коли ні, а потім ми трохи подивимося на навколо одиниці тестування в WordPress загалом.

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

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

Джерело запису: tommcfarlin.com