Тестування 02/11/2022 18:40

Тестуємо вебдодатки за допомогою Laravel та PHPUnit: як правильно писати тести — з прикладами

Senior PHP developer у Binariks

Всім привіт, мене звати Ігор, я PHP-розробник у компанії Binariks. У цій статті я розповім вам про можливості тестування, які надає фреймворк Laravel в поєднанні з PHPUnit, тому запарюйте чайок та готуйтесь до лонгріду 🙂

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

В залежності від ступеня ізоляції тести розділяють на наступні типи:

Unit Tests: максимально ізольовані тести. Використовуються для тестування окремого методу чи функції. Будь-які зовнішні залежності ізолюються на рівні методу чи функції.
Components/Service Tests: тести, які перевіряють роботу та взаємодію окремих компонентів, чи сервісів. Ізолюються в межах тестованого функціоналу.
API/HTTP Tests: тести, що перевіряють те, як працюють окремі АРІ та роботу всіх компонентів, що викликаються при виконанні запиту.
Gui Tests: перевіряють роботу, фронтенд- і бекенд-частини в комплексі.

Як слід проводити тести

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

Тести мають бути швидкими.
Варто уникати надлишкової абстракції в тестах. Код повинен бути читабельним і зрозумілим без надлишкового копання.
Назви тестів повинні бути читабельними.
Test-Driven Development (TDD) — це методологія, коли тести пишуться перед імплементуванням певного функціоналу. Переваги цього підходу в тому, що ви відразу будете писати майбутній код таким чином, щоб його можна було легко тестувати. Також ця методологія зменшує кількість регресивних тестів (тести, що покривають функціонал після його імплементації).
Підготуй, проведи, перевір.

Хороший тест має три стадії:

підготовка — генерування вхідних даних та станів системи;
проведення тесту — проведення дій, потрібних для тесту;
перевірка — проведення дій для перевірки вихідних даних та станів системи.

Тест повинен бути відтворюваним і повертати однаковий результат незалежно від кількості викликів.
Тести не повинні залежати один від одного. Якщо в одного тесту буде залежність від іншого, він може повернути помилку в разі окремого виклику.
Тест має перевіряти тільки один конкретний тестовий сценарій.
Вхідні дані тестів повинні бути реалістичними (використовувати фейкери, для генерування тестових даних — хороша практика).
Якщо для тестування потрібно використовувати базу даних — створіть окрему, на якій ви будете проводити тести.
Уникайте логічних виразів в тестах. На зображенні нижче покажу приклади того, як НЕ ВАРТО РОБИТИ:

Всі зовнішні залежності в тесті повинні бути ізольованими.
Завжди перевіряйте дані відповідними методами. Перевірка даних повинна відбуватися не тільки за значенням, але й за типом.
Для максимальної користі з тестів інтегруйте ваші тести в CI/CD — це допоможе вам уникнути людського фактора, який завжди присутній в розробці.
Покриття тестами має бути максимально можливим. Пишіть тести для різних сценаріїв. Ідеально, коли всі можливі варіанти роботи функціонала покриті тестами. Хорошим показником вважається, коли хоча б 70-80% функціоналу покрито тестами.
Крім всього вище переліченого, тести можуть слугувати прикладами того, як працює функціонал, що тестується. Тому добре розглядати тести як частину специфікації чи документації.

Особливості тестування в Laravel за допомогою PHPUnit

Підтримка тестування за допомогою PHPUnit включена «з коробки», а файл phpunit.xml уже налаштовано для вашої програми. Також у фреймворк додано багато допоміжних методів, які є зручними й спрощують тестування.

За замовчуванням каталог tests в Laravel містить дві папки Feature і Unit.

Unit

Юніт-тести призначені для тестування маленької ізольованої частини вашого коду. Окремого методу класу чи функції.

Тести в директорії Unit не ініціюють ваш Laravel-додаток, тому з юніт-тестами ви не зможете отримати доступ до сервісів Laravel чи бази даних.

Наведу приклад написання юніт-тестів з практичним застосуванням вищеперелічених правил.

Завдання: імплементувати метод getSubscription в класі SubscriptionService, який буде пропонувати користувачеві підписки в залежності від типу його акаунту:

якщо користувач має преміум-акаунт — пропонувати йому преміум-підписки;
якщо у користувача звичайний акаунт — пропонувати йому базові підписки.

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

Створюємо сам функціонал:

Викликаємо тести:

Юніт-тести корисні для перевірки роботи окремих важливих частин коду. Вони швидкі і пишуться відносно просто, дають високу стабільність коду, що покритий тестами.

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

Feature

На відміну від директорії Unit, тести в каталозі Feature призначені для тестування взаємодії різних компонентів програми. Вони ініціюють ваш Laravel-додаток.

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

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

Написання Feature-тестів має кілька особливостей:

Оскільки тести мають доступ до бази даних, для тестування варто створити окрему базу даних, на якій будуть генеруватися і тестуватися дані.
Файл PHPunit.xml дозволить задати чи перезаписати всі .env-змінні (в тому числі і конфігурації, які відповідають). Крім того, ви можете створити файл .env.testing — в такому випадку він буде використовуватися замість .env-файлу при тестуванні.
Для оновлення даних Laravel пропонує трейт Illuminate\ Foundation\ Testing\ RefreshDatabase, який здійснює всі міграції та ініціює транзакцію, яка поверне вашу базу даних до вихідного стану після завершення тесту.
Для генерування тестових даних варто використовувати Faker, Factories, Seeders.
При тестуванні HTTP-запитів варто використовувати функціонал Named Routes — це простий і зручний спосіб генерування складних URL.
Використовуйте Laravel Mocks для логінів, завантаження файлів, Events тощо.

Тестування компонента. Приклад: в модель User потрібно додати scope, який буде фільтрувати записи в базі даних за полем is_admin:

якщо в scope буде передаватися true — повертати всі записи, в яких поле is_admin true;
якщо в scope буде передаватися false — повертати всі записи, в яких поле is_admin false.

Напишемо тест:

Додамо відповідний scope в модель User:

Переконаємося, що тест працює коректно:

Додамо тест для другого випадку:

Перевіримо обидва випадки:

Тестування АРІ. Приклад:

написати тест, який буде перевіряти наступний функціонал;
створити endpoint POST: api/articles;
цей endpoint повинен зберігати в базу даних (user_id (id залогованого користувача), title, text);
доступ до endpoint може мати тільки користувач з правами admin (users.is_admin === true);
при успішному виконанні відповідь з сервера статус 200, та наступні поля.

{
    “user_id”: (id користувача),
    “id”: (article id),
    “title”: (поле title)
}

 
<?php

namespace Tests\Feature;

use App\Models\User;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Illuminate\Foundation\Testing\WithFaker;
use Tests\TestCase;

class CreateArticleTest extends TestCase
{
    use RefreshDatabase;
    use WithFaker;

    public function setUp(): void
    {
        parent::setUp();

        // виключаємо з тесту всі мідлвер, що не відносяться до тесту
        $this->withoutMiddleware();
    }

    public function testCreateArticleSuccess()
    {
        // Створюємо користувача-адміна
        $user = User::factory()->create([
            'is_admin' => true,
        ]);

        // З допомогою фейкера генеруємо дані запиту
        $request = [
            'title' => $this->faker()->text(6),
            'text' => $this->faker()->text(50),
        ];

        // З допомогою методу actingAs() імітуємо поведінку запиту для адміна
        $response = $this->actingAs($user)
            // виконуємо сам запит
            ->post(
                // перший параметр - роут згенерований з допомогою Laravel функціоналу Named routes
                route('articles.create'),
                // Другий параметр - request body
                $request,
            );

        // Перевірка результату:
        // Перевіряємо, чи відповідь з сервера 200
        $response->assertStatus(200)
            // Перевірка структури відповіді
            ->assertJsonStructure([
                'id',
                'user_id',
                'title',
            ])
            // перевірка достовірності отриманих даних
            ->assertJson([
                'user_id' => $user->id,
                'title' => $request['title'],
            ])
            // Конвертуємо відповідь в array, щоб отримати id статті
            ->json();

        // Перевіряємо, чи був створений запис в базі даних
        $this->assertDatabaseHas('articles', [
            'id' => $response['id'],
            'user_id' => $response['user_id'],
            'title' => $response['title'],
            'text' => $request['text'],
        ]);
    }
}

Laravel «з коробки» має багато методів, що будуть корисні при тестуванні. Коротко пройдуся по них і додам корисні посилання (на документацію 🙂 ):

1) HTTP-тести. Назва каже сама за себе — їх мета провести тестування конкретних ендпойнтів сервера. Часто при тестуванні доводиться стикатися з наступними методами фреймворку:

withoutMiddleware() — допомагає відключити всі чи задані Middleware;
withHeaders(), withSession(), withCookies() — імітують наявність в запиті певних хедерів, сесій, кукі;
actingAs() — імітує поведінку сервера при певному авторизованому користувачеві;
get(), post(), put(), patch(), delete(), json() — імітує відповідні методи виклику севера;
assertStatus(), assertJson(), assertJsonStructure() — надають можливість перевірки статус відповіді з сервера та його структури;
view(), blade() — можливість перевірки згенерованих фреймворком сторінок.

2) Методи для імітації роботи функціонала:

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

3) Тестування бази даних:

контроль за міграціями, можливість скасовувати зміни в базі даних після закінчення тесту, методи для тестування наявності (чи відсутності) певних даних в базі даних.

4) Методи для тестування консолі:

фреймворк надає можливості з тестування вхідних та вихідних даних артісанівської консолі;
з встановленням пекеджу Dusk з’являється можливість імітування роботи браузерів і написання GUI-тестів.

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

Сподіваюся, ця стаття буде вам корисною. Всім успіхів!

Читайте також: Як написати односторінковий додаток на Laravel та Vue.js за 45 хвилин

Якщо ви знайшли помилку, будь ласка, виділіть фрагмент тексту та натисніть Ctrl+Enter.