Jedną z cichszych zalet Inertia.js jest testowalność. Ponieważ routing, walidacja i autoryzacja zostają w Laravelu, najcenniejsze testy wyglądają dokładnie jak klasyczne testy feature Laravela — tyle że zamiast HTML sprawdzają komponent strony i propsy. Dodaj do tego warstwę testów komponentów React, a aplikacja Inertia wychodzi lepiej pokryta niż większość SPA, mniejszym kosztem.
Nowa jest dla Ciebie sama architektura?
Inertia.js z Laravel i React — SPA bez osobnego API.
- ## Testy feature: sprawdzaj kontrakt
Helper testowy Inertii zamienia wywołanie kontrolera w asercje o stronie
use Inertia\Testing\AssertableInertia as Assert;
it('lists only the current team orders', function () {
$team = Team::factory()->create();
Order::factory()->count(3)->for($team)->create();
Order::factory()->count(5)->for(Team::factory())->create();
$this->actingAs($team->owner)
->get('/orders')
->assertOk()
->assertInertia(fn (Assert $page) => $page
->component('Orders/Index')
->has('orders.data', 3)
->where('orders.data.0.status', 'new')
);
});
Jeden taki test weryfikuje autoryzację, zakres zapytania, kształt resource'a i nazwę komponentu — cały serwerowy kontrakt strony. Deferred propsy dostają własne asercje: wyślij żądanie uzupełniające i sprawdź, że prop dociera.
Walidacja i przepływy auth
Formularze bolą najbardziej, a testuje się je najłatwiej — reguły żyją w FormRequestach
it('rejects an order without a customer', function () {
$this->actingAs(User::factory()->create())
->post('/orders', ['note' => 'missing customer'])
->assertSessionHasErrors('customer_id');
});
it('redirects guests to login', function () {
$this->get('/orders')->assertRedirect('/login');
});
Ponieważ frontend renderuje błędy z propsów, przetestowanie reguł w Laravelu pokrywa widoczne zachowanie. Po stronie Reacta wystarczy test komponentu, że błędy się renderują, gdy są obecne.
Wskazówka: Testuj szew, nie piksele.
assertInertiasprawdza, co serwer obiecuje frontendowi; testy komponentów — jak frontend to renderuje. Żadne z nich nie potrzebuje przeglądarki.
Testy komponentów po stronie Reacta
Vitest + React Testing Library, skupione na logice
- Komponent tabeli sortuje i paginuje otrzymane propsy.
- Komponent formularza renderuje
errorspod właściwymi polami. - UI zależne od uprawnień ukrywa akcje, gdy prop tak mówi.
Trzymaj je płytko — bez mockowania routera Inertii poza tym, czego komponent faktycznie dotyka. Jeśli komponent potrzebuje pół frameworka do testu, robi za dużo; podziel go.
- ## End-to-end: mały, chroniony zestaw
Testy przeglądarkowe są wolne i niestabilne; używaj ich tam, gdzie tylko prawdziwa przeglądarka dowodzi racji: logowanie → nawigacja → utworzenie zamówienia → obecność na liście. W Playwright jedna taka ścieżka na krytyczny moduł. Reszta zostaje w dwóch warstwach wyżej.
Jak wygląda piramida w praktyce
W naszych projektach Inertia mniej więcej: 70% testy feature Laravela (kontrakt, reguły, auth), 20% testy komponentów (logika renderowania), 10% ścieżki Playwright. Zestaw leci w CI przy każdym pushu, a deploye są nudne — i o to chodzi. Ta sama filozofia obowiązuje w reszcie stacku, co widać w sposobie, w jakim wyceniamy projekty w usłudze tworzenia aplikacji Laravel.
FAQ
Jak sprawdzić komponent strony i propsy?
Użyj assertInertia z traitem AssertableInertia — nazwa komponentu i struktura propsów w jednym wywołaniu, przeciw prawdziwemu kontrolerowi.
Czy potrzebuję testów E2E w przeglądarce?
Tylko dla krytycznych ścieżek. Testy feature z assertInertia pokrywają kontrakt danych znacznie taniej; Playwright chroni klej.
Co testować po stronie Reacta?
- Komponenty z logiką: sortowanie tabel, formularze z błędami, renderowanie po uprawnieniach. Vitest + React Testing Library, płytko.
👉 Chcesz suite testów, przy którym deploye są nudne? Zobacz tworzenie aplikacji Laravel albo programista Laravel na zlecenie.
📖 Czytaj dalej: Inertia.js z Laravel i React, formularze i walidacja w Inertia.js i Inertia.js i TypeScript.