Велика кількість веб-додатків, які ми тестуємо в TestMatick, побудовані на безкоштовному веб-фреймворку з відкритим вихідним кодом - Laravel.

Можна з упевненістю сказати, що [highlight dark=”no”]Laravel повністю підтримує тестове середовище PHPUnit у своєму ядрі[/highlight]. Як відомо, PHPUnit є найпопулярнішим фреймворком для тестування функціональності PHP-коду. Він допомагає нам легко створювати 2 типи тестів - модульні та функціональні.

Ми почнемо аналіз можливостей фреймворку Laravel з його основ, а саме з визначення модульного та функціонального тестування. У міру просування вперед ми побачимо повну картину розробки модульних і функціональних тестів у додатку.

Функціональні та модульні тести

Якщо ви знайомі з роботою з PHPUnit, то повинні розуміти, що будь-яке тестування в цьому середовищі можна легко розділити на 2 категорії: модульне тестування і функціональне тестування.

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

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

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

Приклад коду

Відповідно до написаних функцій, метод виконує лише одну запрограмовану дію. Він використовує функцію ucfirst для швидкого перетворення одного заголовка на інший з великими літерами.

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

Хорошим прикладом є те, що ви, як QA, можете виконувати функціональне тестування для певної групи вхідних параметрів, яке зазвичай складається з наступних кроків:

• Розробка GET-запиту для доступу до сторінки входу в систему;
• Перевірка правильності відображення сторінки;
• Створення POST-запиту для негайного відправлення даних на веб-сторінку з вашим логіном;
• Перевірка успішності створеної сесії.

Тільки так ви зможете швидко і ефективно створити функціональний тестовий кейс. У наступних розділах ми розберемо прості приклади того, як ефективно і швидко створювати прості функціональні та модульні тести в додатку на Laravel.

Забезпечення передумов

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

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

Спеціальна команда ремісників

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

Розвинутий клас постової моделі має виглядати так:

Розвинутий клас постової моделі

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

Розташування файлу міграції

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

Структура файлу міграції

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

Спеціальна колонка

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

Команда міграції

Тоді вам слід повністю змінити використовувану модель посту на наступну:

Пост-модель

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

Тепер наше завдання - створити файловий контейнер, який допоможе нам розробити необхідний сценарій функціонального тестування на завершальному етапі тестування.

Файловий контейнер

Сценарій функціонального тестування

Усередині методу індексу ми повинні спробувати витягти ідентифікатор повідомлення з набору параметрів нашого запиту з подальшим завантаженням моделі посту.

Вкажіть шлях до потрібного файлу:

Шлях до потрібного файлу

Модульне тестування програми на Laravel

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

Зазвичай, утиліта Laravel є ремісничою командою, яка допомагає тестувальникам погратися з класичним типовим класом свого юніт-тесту.

Запустимо цю команду, щоб створити спеціальний клас AccessorTest . [highlight dark=”no”]У цьому випадку дуже важливо мати слово “unit”, яке допомагає створити юніт-тест, розташований у вказаному каталозі tests/unit.[/highlight]

Тестовий приклад модуля

Ця маніпуляція допоможе нам створити всередині нього наступний важливий клас:

Клас “А

Клас “А

Додайте до нього “корисний” програмний код:

Програмний код

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

Отже, ми закінчили з юніт-тестуванням в Laravel!

Функціональне тестування

По-перше, нам потрібно створити передумови для роботи в середовищі функціонального тестування (в нашому випадку AccessorTest). Оскільки ми не використовуємо функціональний вираз - unit, вся наша робота буде розглядатися як багатофункціональний тестовий кейс з переміщенням в спеціальний каталог - tests/feature.

Це допоможе створити необхідний клас:

Необхідний клас

Потім змініть все на необхідний програмний код:

Необхідний програмний код

Ми повинні повторити ще раз: цей код повинен виглядати знайомим для нас, особливо якщо ви знайомі з функціональним тестуванням.

Отже, що ми отримали: по-перше, ми змогли витягти пост зі згаданої бази даних і знаємо, що значення всередині $db_post_title зміниться. Тоді ми зможемо змоделювати запит “GET” і записати отриману відповідь у змінну $response.

Потім ми проаналізували код відповіді всередині змінної $response з очікуваною відповіддю. Згідно з нашими вихідними даними, вона має бути [highlight dark=”no”]200[/highlight], оскільки ми повинні отримати реальний звіт по GET-запиту. Також у відповіді повинен бути вказаний спеціальний заголовок, який починається з верхнього регістру, а це саме те, що нам потрібно в процесі взаємодії з методом assertSeeText.

Декілька слів про інтеграційне тестування в Laravel

Взаємодія з інтеграційними тестами - це поєднання виконання встановлених метрик в процесі взаємодії з певним візуальним продуктом. Такі тест-кейси повністю відрізняються від типових юніт-тестів, які тестують незалежні одна від одної частини утиліти.

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

За своєю природою кожен інтеграційний тест взаємодіє з додатком Laravel так само, як з простим чорним ящиком.

Їх не “хвилює”, що знаходиться всередині утиліти, отриманий результат - понад усе.

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

В процесі вивчення можливостей тестування в Laravel ми створили кілька хороших прикладів, які допомагають зрозуміти, як насправді швидко створювати модульні та функціональні тестові кейси на основі сформованої ремісничої команди.