Testy automatyczne w Laravel — PHPUnit i Pest w praktyce [2026]

Testy automatyczne to najtańsze ubezpieczenie aplikacji Laravel. Koszt ich wdrożenia to zwykle 3 000–15 000 zł netto + VAT, a brak testów oznacza, że każda zmiana w kodzie jest ryzykiem regresji — a koszt naprawy błędu na produkcji bywa kilkukrotnie wyższy niż napisanie testu. W tym poradniku pokażę, jak testować aplikacje Laravel z PHPUnit i Pest, co testować w pierwszej kolejności i jak wpiąć testy w proces wdrożeniowy.

Jeśli budujesz aplikację, którą będziesz rozwijać przez lata, testy nie są opcją — są warunkiem, żeby rozwój nie zamienił się w gaszenie pożarów.

Po co testować aplikację Laravel?

Testy automatyczne rozwiązują cztery problemy, które zna każdy zespół rozwijający oprogramowanie.

• Regresje — po każdej zmianie testy sprawdzają, czy nie zepsułeś tego, co działało. Bez nich weryfikacja opiera się na klikaniu i pamięci.
• Refactoring — porządkowanie kodu bez testów to hazard. Z testami możesz przebudować moduł i w ciągu minuty sprawdzić, czy nic się nie zepsuło.
• Dokumentacja — testy pokazują, jak system ma się zachowywać. Nowa osoba w zespole czyta testy zamiast zgadywać.
• Pewność wdrożeń — pipeline z testami blokuje wdrożenie, gdy coś nie działa. To jedna z największych oszczędności czasu w całym procesie.

Najważniejsze: Testy automatyczne w Laravel to inwestycja rzędu 3 000–15 000 zł netto + VAT przy typowym projekcie. Zwracają się przy pierwszej poważnej zmianie w kodzie — koszt błędu na produkcji (utracone zamówienia, dane, zaufanie klientów) jest zwykle wielokrotnie wyższy.

Testy jednostkowe, feature i integracyjne — czym się różnią?

W Laravelu spotkasz trzy podstawowe typy testów. Dobrze zaprojektowany zestaw używa wszystkich, w odpowiednich proporcjach.

Najczęstszy błąd to testowanie wyłącznie jednostkowo. Testy jednostkowe są szybkie, ale nie wychwycą błędów w routingu, uprawnieniach czy migracjach. W praktyce najlepiej działają testy feature pisane z perspektywy użytkownika systemu.

PHPUnit w Laravel — od czego zacząć?

PHPUnit to domyślny framework testowy Laravela — nie musisz nic instalować. Test tworzysz jednym poleceniem.

php artisan make:test OrderTest

Przykładowy test feature, który sprawdza, czy zalogowany użytkownik może złożyć zamówienie.

public function test_user_can_place_an_order()
{
    $user = User::factory()->create();

    $response = $this->actingAs($user)->post('/orders', [
        'product_id' => Product::factory()->create()->id,
        'quantity' => 2,
    ]);

    $response->assertStatus(201);
    $this->assertDatabaseHas('orders', [
        'user_id' => $user->id,
        'quantity' => 2,
    ]);
}

Zwróć uwagę na trzy elementy tego testu. Po pierwsze, używa fabryk danych zamiast ręcznego tworzenia rekordów. Po drugie, sprawdza zarówno odpowiedź HTTP, jak i stan bazy danych. Po trzecie, opisuje zachowanie biznesowe, a nie implementację.

Ważne ustawienie to RefreshDatabase — dzięki niemu każdy test uruchamia się na czystej bazie. Testy nie zależą od siebie i nie zostawiają śmieci.

Pest — nowocześniejsza alternatywa dla PHPUnit

Pest to framework testowy zbudowany na PHPUnit, ale z czytelniejszą składnią. Ten sam test w Pest wygląda tak.

it('allows a user to place an order', function () {
    $user = User::factory()->create();

    $this->actingAs($user)
        ->post('/orders', [
            'product_id' => Product::factory()->create()->id,
            'quantity' => 2,
        ])
        ->assertStatus(201);

    expect(Order::count())->toBe(1);
});

Porównanie obu narzędzi w praktyce.

W obu przypadkach możesz uruchamiać testy poleceniem php artisan test. Pest nie zamyka drogi do PHPUnit — pod spodem to ten sam silnik, więc migracja w obie strony jest płynna.

Co testować w pierwszej kolejności?

Nie da się przetestować wszystkiego od razu — i nie trzeba. Zacznij od ścieżek, których awaria kosztuje najwięcej.

• Uwierzytelnianie i autoryzacja — logowanie, role, dostęp do danych innych użytkowników. Błąd tutaj to wyciek danych.
• Płatności i zamówienia — pełna ścieżka zakupu, statusy, faktury, zwroty. Każdy błąd to realne pieniądze.
• Integracje zewnętrzne — webhooki, synchronizacja stanów, obsługa błędów API. Testuj scenariusze awarii, nie tylko happy path.
• Endpointy API — kody odpowiedzi, walidacja, limity. API to kontrakt z frontendem i partnerami.
• Procesy administracyjne — zatwierdzenia, eksporty, raporty. Błędy tutaj generują pracę ręczną.

Wskazówka: Zasada praktyczna — najpierw pokryj testami wszystko, co dotyka pieniędzy i danych osobowych. Dopiero potem resztę. Taki zestaw testów daje największą ochronę przy najmniejszym nakładzie pracy.

Testy w procesie CI/CD

Testy mają największą wartość, gdy uruchamiają się automatycznie przy każdym pushu do repozytorium. GitHub Actions wykonuje cały zestaw w kilka minut i blokuje wdrożenie, jeśli cokolwiek nie przechodzi. Jak skonfigurować taki pipeline, opisałem w artykule CI/CD i DevOps dla aplikacji Laravel.

Pipeline z testami daje jeszcze jedną rzecz — dyscyplinę. Nie da się „zapomnieć" uruchomić testów, bo za każdym razem robi to serwer.

Pokrycie kodu — ile procent wystarczy?

Pokrycie kodu (code coverage) to wskaźnik, ile linii kodu wykonują testy. To użyteczna metryka, ale bywa pułapką.

• 100% pokrycia nie oznacza braku błędów — testy mogą wykonywać kod, ale nie sprawdzać efektów.
• 0% pokrycia na krytycznych ścieżkach to realne ryzyko — tu warto dążyć do pełnego pokrycia.
• W praktyce sensowne minimum dla aplikacji biznesowej to 60–80% pokrycia, ze 100% na płatnościach, autoryzacji i integracjach.

Mierz pokrycie, ale nie traktuj go jako celu samego w sobie. Celem jest pewność, że kluczowe scenariusze działają po każdej zmianie.

Testy w projektach legacy

W starym kodzie bez testów zaczynasz inaczej — od testów regresji na istniejącym zachowaniu. Najpierw opisujesz testem to, jak system działa dzisiaj (nawet jeśli nieidealnie), a dopiero potem refaktoryzujesz. Ten proces krok po kroku opisałem w artykule modernizacja legacy code i w usłudze modernizacji legacy PHP.

Bez testów regresji refaktoryzacja starego systemu to lot bez przyrządów. Z nimi każdy krok jest weryfikowalny i odwracalny.

Ile kosztuje wdrożenie testów w projekcie?

Koszt zależy od stanu projektu i zakresu krytycznych ścieżek. Orientacyjnie, netto + VAT

• Nowy projekt w Laravel — testy w standardzie, wliczone w stawkę godzinową 90–160 zł/h.
• Wdrożenie testów w istniejącym projekcie — 3 000–15 000 zł, zależnie od liczby modułów krytycznych.
• Testy regresji przed refactoringiem legacy — wyceniane po audycie, zwykle 2 000–8 000 zł za moduł.

Najlepszy moment na testy to pierwszy dzień projektu — im później, tym drożej. Jeśli chcesz sprawdzić, jak wyglądałby taki zakres w Twojej aplikacji, opisz projekt w formularzu kontaktowym — wycena jest bezpłatna. Budujesz nowy system? Zobacz usługę Laravel Development albo programistę Laravel na zlecenie.

Najczęściej zadawane pytania

Ile kosztuje wdrożenie testów automatycznych w Laravel?

Wdrożenie testów w istniejącym projekcie kosztuje orientacyjnie 3 000–15 000 zł netto + VAT, zależnie od liczby krytycznych modułów. W nowych projektach testy są częścią standardu i mieszczą się w stawce godzinowej 90–160 zł/h.

Pest czy PHPUnit — co wybrać w 2026?

Oba narzędzia działają na tym samym silniku. Pest ma czytelniejszą składnię i lepiej sprawdza się w nowych projektach oraz zespołach, które cenią zwięzłość. PHPUnit to bezpieczny wybór w istniejących projektach i zespołach, które już go znają. Nie musisz wybierać raz na zawsze — można je łączyć.

Ile procent pokrycia kodu wystarczy?

Dla typowej aplikacji biznesowej sensowne minimum to 60–80%. Kluczowe obszary — płatności, autoryzacja i integracje — warto pokryć w 100%. Sam wskaźnik pokrycia nie gwarantuje jakości, liczy się jakość asercji.

Czy warto pisać testy do starego kodu bez testów?

Tak, ale inaczej — zaczynasz od testów regresji opisujących obecne zachowanie systemu, a dopiero potem refaktoryzujesz. To jedyny bezpieczny sposób modernizacji legacy. Koszt takiego podejścia jest zwykle niższy niż naprawa awarii po niekontrolowanej zmianie.

Czy testy spowalniają development?

Źle napisane testy potrafią spowalniać. Dobrze napisany zestaw feature testów działa w minutach i paradoksalnie przyspiesza pracę — bo eliminuje ręczne klikanie po każdym wdrożeniu i skraca cykl naprawy błędów z dni do minut.

Od czego zacząć testowanie w Laravel?

Od trzech rzeczy. Skonfiguruj php artisan test i bazę testową, napisz pierwszy test feature dla logowania, a potem pokryj testami ścieżkę zakupu lub inny proces krytyczny biznesowo. Dopiero potem rozszerzaj zakres i wpinaj testy w CI/CD.

👉 Chcesz, żeby Twoja aplikacja Laravel była pokryta testami? Sprawdź usługę Laravel Development albo opisz projekt na kontakt@informatix.com.pl — wycena jest bezpłatna.

📖 Zobacz również: CI/CD i DevOps dla aplikacji Laravel, bezpieczeństwo aplikacji Laravel — OWASP Top 10 oraz modernizacja legacy code krok po kroku.