<? phpukraine ДОКУМЕНТАЦІЯ
Пошук по платформі
Документація українською

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

ВЕРСІЯ
АКТУАЛЬНА Актуальний реліз. Переклад наздоганяє оригінал, розділи з низьким відсотком позначені у змісті.
ТЕСТУВАННЯ · ПЕРЕКЛАДЕНО оновлено 15 вересня 2026

Початок роботи · Laravel

Вступ

Laravel створений із думкою про тестування. Підтримка Pest і PHPUnit працює одразу після встановлення, а файл phpunit.xml уже налаштований для вашого застосунку. Фреймворк також постачається зі зручними допоміжними методами, які дозволяють виразно тестувати ваші застосунки.

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

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

Файл ExampleTest.php є в обох теках, Feature і Unit. Після встановлення нового застосунку Laravel виконайте команду vendor/bin/pest, vendor/bin/phpunit або php artisan test, щоб запустити тести.

Середовище

Під час запуску тестів Laravel автоматично встановлює оточення конфігурації у значення testing завдяки змінним середовища, визначеним у файлі phpunit.xml. Laravel також автоматично налаштовує сесію та кеш на драйвер array, тому дані сесії й кешу не зберігатимуться під час тестування.

Ви можете визначати інші значення конфігурації тестового середовища за потреби. Змінні середовища testing налаштовуються у файлі phpunit.xml вашого застосунку, але не забудьте очистити кеш конфігурації Artisan-командою config:clear перед запуском тестів!

Файл середовища .env.testing

Крім того, ви можете створити файл .env.testing у корені проєкту. Його буде використано замість файлу .env під час запуску тестів Pest і PHPUnit або виконання Artisan-команд з опцією --env=testing.

Створення тестів

Щоб створити новий тестовий клас, скористайтеся Artisan-командою make:test. За замовчуванням тести потрапляють у теку tests/Feature:

php artisan make:test UserTest

Якщо ви хочете створити тест у теці tests/Unit, додайте опцію --unit під час виконання команди make:test:

php artisan make:test UserTest --unit

Якщо тестовий клас переважно спирається на можливості тестування Laravel, але конкретному тестовому методу завантажений фреймворк не потрібен, застосуйте до цього методу атрибут #[UnitTest], щоб пропустити завантаження застосунку саме для нього.

<?php

namespace Tests\Feature;

use Illuminate\Foundation\Testing\Attributes\UnitTest;
use Tests\TestCase;

class LocationServiceTest extends TestCase
{
    public function test_get_coordinates_resolves_address(): void
    {
        // Цей тест використовує можливості тестування Laravel...
    }

    #[UnitTest]
    public function test_get_state_returns_state_from_abbreviation(): void
    {
        // Цей тест виконується без завантаження застосунку...
    }
}

Примітка Заготовки тестів можна змінювати за допомогою публікації заготовок.

Після того як тест згенеровано, описуйте його так, як звикли робити це в Pest або PHPUnit. Щоб запустити тести, виконайте в терміналі команду vendor/bin/pest, vendor/bin/phpunit або php artisan test:

// Pest
<?php

test('basic', function () {
    expect(true)->toBeTrue();
});
// PHPUnit
<?php

namespace Tests\Unit;

use PHPUnit\Framework\TestCase;

class ExampleTest extends TestCase
{
    /**
     * Базовий приклад тесту.
     */
    public function test_basic_test(): void
    {
        $this->assertTrue(true);
    }
}

Увага Якщо ви визначаєте власні методи setUp / tearDown у тестовому класі, обовʼязково викликайте відповідні методи батьківського класу parent::setUp() / parent::tearDown(). Зазвичай parent::setUp() викликають на початку власного методу setUp, а parent::tearDown() - у кінці методу tearDown.

Запуск тестів

Як згадувалося раніше, коли тести написані, ви можете запустити їх через pest або phpunit:

# Pest
./vendor/bin/pest
# PHPUnit
./vendor/bin/phpunit

Крім команд pest і phpunit, для запуску тестів можна використовувати Artisan-команду test. Artisan-раннер тестів дає докладні звіти, що полегшує розробку й налагодження:

php artisan test

Будь-які аргументи, які можна передати командам pest чи phpunit, приймає й Artisan-команда test:

php artisan test --testsuite=Feature --stop-on-failure

Паралельний запуск тестів

За замовчуванням Laravel і Pest / PHPUnit виконують тести послідовно в одному процесі. Проте час проходження набору тестів можна значно скоротити, запустивши їх одночасно в кількох процесах. Для початку встановіть Composer-пакет brianium/paratest як «dev»-залежність. Далі додайте опцію --parallel під час виконання Artisan-команди test:

composer require brianium/paratest --dev

php artisan test --parallel

За замовчуванням Laravel створить стільки процесів, скільки ядер CPU доступно на вашій машині. Кількість процесів можна змінити опцією --processes:

php artisan test --parallel --processes=4

Увага Під час паралельного запуску тестів деякі опції Pest / PHPUnit (наприклад, --do-not-cache-result) можуть бути недоступні.

Паралельне тестування і бази даних

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

За замовчуванням тестові бази зберігаються між викликами Artisan-команди test, щоб їх можна було використати повторно під час наступних запусків. Проте ви можете створити їх наново опцією --recreate-databases:

php artisan test --parallel --recreate-databases

Хуки паралельного тестування

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

За допомогою фасаду ParallelTesting ви можете вказати код, який виконається на setUp і tearDown процесу або тестового класу. Передані замикання отримують змінні $token і $testCase, що містять токен процесу та поточний тестовий клас відповідно:

<?php

namespace App\Providers;

use Illuminate\Support\Facades\Artisan;
use Illuminate\Support\Facades\ParallelTesting;
use Illuminate\Support\ServiceProvider;
use PHPUnit\Framework\TestCase;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Завантаження будь-яких сервісів застосунку.
     */
    public function boot(): void
    {
        ParallelTesting::setUpProcess(function (int $token) {
            // ...
        });

        ParallelTesting::setUpTestCase(function (int $token, TestCase $testCase) {
            // ...
        });

        // Виконується під час створення тестової бази даних...
        ParallelTesting::setUpTestDatabase(function (string $database, int $token) {
            Artisan::call('db:seed');
        });

        ParallelTesting::tearDownTestCase(function (int $token, TestCase $testCase) {
            // ...
        });

        ParallelTesting::tearDownProcess(function (int $token) {
            // ...
        });
    }
}

Доступ до токена паралельного тестування

Якщо вам потрібен доступ до «токена» поточного паралельного процесу з будь-якого іншого місця тестового коду застосунку, скористайтеся методом token. Цей токен - унікальний рядковий ідентифікатор окремого тестового процесу, за яким можна розділяти ресурси між паралельними тестовими процесами. Наприклад, Laravel автоматично додає цей токен у кінець імен тестових баз даних, створених кожним паралельним тестовим процесом:

$token = ParallelTesting::token();

Звіт про покриття тестами

Увага Ця можливість потребує Xdebug або PCOV.

Запускаючи тести застосунку, ви можете захотіти зʼясувати, чи справді ваші тести покривають код застосунку і яка його частина задіяна під час прогону. Для цього передайте опцію --coverage під час виклику команди test:

php artisan test --coverage

Встановлення мінімального порога покриття

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

php artisan test --coverage --min=80.3

Профілювання тестів

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

php artisan test --profile

Кешування конфігурації

Під час запуску тестів Laravel завантажує застосунок для кожного окремого тестового методу. Без кешованого файлу конфігурації кожен конфігураційний файл застосунку доводиться завантажувати на початку тесту. Щоб зібрати конфігурацію один раз і використати її для всіх тестів одного прогону, застосуйте трейт Illuminate\Foundation\Testing\WithCachedConfig:

// Pest
<?php

use Illuminate\Foundation\Testing\WithCachedConfig;

pest()->use(WithCachedConfig::class);

// ...
// PHPUnit
<?php

namespace Tests\Feature;

use Illuminate\Foundation\Testing\WithCachedConfig;
use Tests\TestCase;

class ConfigTest extends TestCase
{
    use WithCachedConfig;

    // ...
}
ЯК ЦЯ СТОРІНКА ВИГЛЯДАЄ В ПОШУКУ
phpukraine.com/docs/laravel/testing
Початок роботи | Документація Laravel українською
Початок роботи у Laravel 13.x: переклад офіційної документації українською. Оновлено 15 вересня 2026. Приклади коду, пояснення та посилання на питання зі співбесід.
Стан перекладу

Перекладаємо з офіційної документації, розділ за розділом, і не ховаємо недоперекладене. Помітили неточність у терміні чи реченні: напишіть, виправимо.

90%
Готовності
10
У роботі
0
Ще не перекладено
Глосарій термінів