Частина 9 Codeception

Щоб не забути

Нотатник розсіяного [у просторі та часі] програміста

Частина 9: Codeception. Налаштування. Unit-тести (Тестування ПЗ)

Зміст

Продовжуємо цикл статей Тестування ПЗ. У цій частині розглянемо встановлення та налаштування фреймворку codeception. Принагідно перенесемо всі раніше написані тести на нову платформу.

Перш, ніж рухатися далі, нам необхідно познайомитися з таким фреймворком як codeception. На базі PHPUnit можна робитилише блокові та модульні тести. Його призначення повністю розшифровується у назві. Оскільки спочатку він був заточений під застосування виключно для юніт-тестування (і звичайного модульного).

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

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

Раніше виділялося чотири стадії тестування проекту:

юніт-тестування
інтеграційне - воно ж блокове
функціональне
приймальне

Було зазначено, що в рамках yii здійснювати суто блочне тестування не завжди можливе через його архітектурні особливості.

Codeception дещо спрощує життя розробника. В рамках цього інструменту існує три рівні ізоляції тестів.

Юніт-тести. Цей рівень ізоляції поєднує як стандартні юніт-тести, так і блокові.
Функціональні тести - це, як і раніше, відправлення даних у форми, перевірка відповіді сервера, тестування зовнішнього api.
Приймальні тести – запускається headless-браузер (вікна не відкривається, браузер працюєу фоновому режимі) та фреймворк виконує дії від імені користувача: рухає мишкою, вводить текст у поля введення, розгадує капчу, переходить по пунктах меню. Ця частина тестів здатна знаходити помилки у коді браузерних програм.

встановлення та ініціалізація

Нам буде потрібний пакет codeception/codeception — основна складова фреймворку.

Конструкція означає, що ми ставимо запитуємо останню версію з гілки 2.x. Виконуємо цю команду на віртуальній машині у папці/var/www.

Далі варто поставити codeception/verify – досить зручний пакет, який дозволяє писати предикати, близькі до природної мови. Це лише синтаксичний цукор. Порівняйте два тести, які описані нижче – перший із застосуванням стандартних предикатів, а другий – із синтаксичним цукром.

Ставиться досить просто.

Останнє, що нам може знадобитися – це модуль codeception/specify. Ще одна порція синтаксичного цукру. Трохи згодом ми будемо застосовувати її на практиці.

Не забуваймо вказувати опцію -dev - вона говорить про те, що при розгортанні нашого проекту в релізі пакети для виконання тестів або будь-якої іншої девелоперської рутини не буде встановлено.

Інший простий спосіб встановити описані вище компоненти - це додати до секції require-dev кілька пакетів і виконати провізію на машині.

Інтеграція Codeception та Yii2

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

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

Каталог із загальними тестами для всього проекту буде створено в папці common. Так, ми не будемо далі використовувати виклик через composer run через баг, який був описаний раніше. Опція -ns для нас життєво необхідна для того, щоб усі генеровані фреймворком у процесі роботи файли потрапляли в правильний неймспейс відразу (це файли з каталогу tests/_generated).

Також у каталозі common буде створено файл codeception.yml – це конфігурація для запуску.

Спочатку codeception не вміє дружити з yii2 повноцінно. Тому нам потрібно його цього навчити. Один із параметрів файлу налаштування вказує на _bootstrap.php - скрипт, який виконується перед запуском тестів. Ось тут ми і виконаємо завантаження базової частини фреймворку на згадку.

Тепер додамо потрібні для подальшої роботи параметри codeception.yml.

Чому так відбувається? Раніше ми вказували шлях до тестової конфігурації проекту у файлах настроювання оточення. Так ось. TestCase з PHPUnit нічого про це оточення не знає, а отже він нічого не знає про ініціалізацію yii. З цього випливає, що об'єкт \Yii::$app нам недоступний і ми не можемо витягувати з нього залежність.

Як бути? Відспадкуватися від Codeception Test Unit. Цей клас вже знає, що потрібно робити для запуску двигуна перед тестами. Якщо ми заглянемо у вихідники цього класу, то знайдемо там код, який відповідає за ініціалізацію модулів (налаштування беруться з масиву part для кожного типу кейсів).

Повторний запуск та всі тести завершуються коректно.

Перенесення тестів DBUnit

У нас є LoginFormTest, якийвикористовує функціонал DBUnit для додавання сутностей до бази даних. Як із ним бути? Все досить просто - у yii є механізм acrivefixture, який підмішує в базу потрібні дані і являє собою іншу реалізацію того, що являє собою DBUnit.

Найбільш поширене завдання розширення для роботи з базою зі складу PHPUnit — завантажити дані (не розглядатимемо завдання валідації схем — рідко хто з користувачів готових фреймворків нею користується). Щоб це зробити нам потрібно кілька простих речей:

Проініціалізувати клас фікстури для потрібної моделі. В даному випадку це common fixtures User
Створити сховище, в якому містяться дані фейкових користувачів (common/tests/_data/User.php )
Змінити порядок успадкування класу LoginFormTest та успадкувати його від Codeception/Test/Unit
Видалити всі методи, які були реалізовані для DBUnit
Реалізувати метод _before, який містить підвантаження фікстури
Додати підтримку fixtures у налаштування unit.suite.yml
Пам'ятаєте ми додавали збереження модулів фреймворку, які ми обертали в mock'і? Цей функціонал потрібно прибрати - налаштування codeception за умовчанням ініціалізують оточення yii законо ля кожного тесту.

Поділ тестів на фронтенд, бекенд та core-складові

Безперечно, можна звалювати всі тести в одну купу (ядро, бек, фронт) і запускати їх однією командою. Так, наприклад, зроблено в yii2-standard-template. Але коли проект у нас складний, то час виконання тестів безперервно зростає і треба якось розділяти їх на блоки, а для цього у нас є чудова нагода — сама архітектура додатку цьому сприяє, оскільки поділена на три частини.

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

У нашому випадку це файл codeception.yml у корені проекту.

Розробники шаблону про нас подбали і наперед усе зробили до нас. Ми лише повторили їхній шлях. І тепер можна запускати тести вже й до кореня проекту. При такому способі будуть виконані всі юніт та функціональні тести для всіх блоків системи.

Навіщо все це?

Після виконання всіх дій виникає запитання: розробники yii2-advanced-template вже все зробили до нас (поклали потрібні файли в потрібні місця, налаштували оточення), навіщо нам повторювати цей шлях? Звичайно для того, щоб знати, як влаштовані подібні речі зсередини. У наступних частинах ми вже перейдемо безпосередньо до самих тестів, а зараз ми лише вчимося, опановуємо технологію.

Домашнє завдання

Найголовніша проблема нашого кейсу: ми тестували функціонал фронтенду всередині тестів, присвячених ядру системи (я про LoginForm). Доцільно винести ці тести у frontend-складову, яку ви і зробите як домашню роботу.

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