Pest adaugă o sintaxă expresivă peste PHPUnit; Laravel oferă helpers pentru HTTP, baze de date și fake-uri pentru mail/queue. Discuția nu presupune acoperire completă, ci un punct de pornire: ce merită testat primul într-un forum sau site cu formulare autentificate, acolo unde regresia ar fi vizibilă utilizatorilor.
Testele de feature lovește rute reale cu `get/post` și assert pe status, redirect sau fragment HTML/JSON. Sunt mai lente dar prind integrarea middleware, validare și DB. Testele unitare izolează o clasă cu mock-uri — utile pentru reguli de slug sau calcul de permisiuni. Nu testa framework-ul; testează comportamentul tău specific. Începe cu „happy path” login, creare post, apoi cazuri 403/422 — acoperă fluxurile care generează cele mai multe bug-uri raportate.
Trait-ul RefreshDatabase rulează migrări (sau tranzacții) între teste; combină cu factories pentru utilizatori și postări. Evită dependența de ordinea testelor — fiecare scenariu își creează datele. Pentru SQLite in-memory, verifică compatibilitatea migrărilor cu tipuri MySQL specifice. Seedere global greu în `TestCase` încetinește tot suite-ul; preferă factories per test.
Mail::fake() confirmă trimiterea fără SMTP real; Queue::fake() verifică dispatch fără worker. Event::fake() opțional când evenimentele declanșează lanțuri grele. Assert pe conținutul mail-ului (subiect, link) prinde regresii la template-uri de verificare email. Notification::fake() acoperă canale multiple fără a trimite push sau database entries nedorite.
Gruparea fișierelor `tests/Feature/Forum/` menține suite-ul navigabil. Rulează `./vendor/bin/pest --parallel` doar dacă testele sunt independente. În pipeline CI, folosește `.env.testing` cu credențiale izolate; nu atinge producția. Un test flaky e dator uneori timpului (`now()` necontrolat) — folosește `Carbon::setTestNow` sau injectează clock-ul. Eșecul unui test trebuie să explice ce comportament s-a rupt, nu doar diff de array — mesaje assert clare economisesc timp la review.
Feature versus unit
Testele de feature lovește rute reale cu `get/post` și assert pe status, redirect sau fragment HTML/JSON. Sunt mai lente dar prind integrarea middleware, validare și DB. Testele unitare izolează o clasă cu mock-uri — utile pentru reguli de slug sau calcul de permisiuni. Nu testa framework-ul; testează comportamentul tău specific. Începe cu „happy path” login, creare post, apoi cazuri 403/422 — acoperă fluxurile care generează cele mai multe bug-uri raportate.
Baza de date în teste
Trait-ul RefreshDatabase rulează migrări (sau tranzacții) între teste; combină cu factories pentru utilizatori și postări. Evită dependența de ordinea testelor — fiecare scenariu își creează datele. Pentru SQLite in-memory, verifică compatibilitatea migrărilor cu tipuri MySQL specifice. Seedere global greu în `TestCase` încetinește tot suite-ul; preferă factories per test.
Fake-uri pentru efecte secundare
Mail::fake() confirmă trimiterea fără SMTP real; Queue::fake() verifică dispatch fără worker. Event::fake() opțional când evenimentele declanșează lanțuri grele. Assert pe conținutul mail-ului (subiect, link) prinde regresii la template-uri de verificare email. Notification::fake() acoperă canale multiple fără a trimite push sau database entries nedorite.
Organizare și CI
Gruparea fișierelor `tests/Feature/Forum/` menține suite-ul navigabil. Rulează `./vendor/bin/pest --parallel` doar dacă testele sunt independente. În pipeline CI, folosește `.env.testing` cu credențiale izolate; nu atinge producția. Un test flaky e dator uneori timpului (`now()` necontrolat) — folosește `Carbon::setTestNow` sau injectează clock-ul. Eșecul unui test trebuie să explice ce comportament s-a rupt, nu doar diff de array — mesaje assert clare economisesc timp la review.