Pe scurt: PHPUnit este instrumentul standard pentru testarea automată a codului PHP; Pest este un framework construit pe el, cu scriere mai scurtă. Actuală este PHPUnit 13 (din februarie 2026, de la PHP 8.4), iar Pest este în versiunea 5. Testele automate nu închid vulnerabilități din PHP însuși, dar fac actualizările previzibile: după PHP2Shell și înainte de sfârșitul suportului pentru PHP 8.2, la 31.12.2026, acesta este avantajul decisiv.
De ce să testați codul PHP?
Pentru conducere, beneficiul se rezumă într-o frază: testele fac modificările mai ieftine și mai sigure. Un test automat verifică în câteva secunde dacă o funcție mai face ce trebuie, de exemplu dacă un coș de cumpărături calculează corect sau dacă o autentificare respinge parolele greșite. Fără teste, această verificare o face un om manual, sau nimeni.
Diferența devine deosebit de clară la actualizări. Dacă PHP trebuie actualizat pe termen scurt din cauza unei vulnerabilități critice, mulți operatori ezită, de teama erorilor în magazin sau în portalul de clienți. Cu o suită de teste, actualizarea rulează mai întâi într-un mediu de test, testele arată problemele, iar abia apoi se trece live.
PHPUnit: standardul pentru testele PHP
PHPUnit apare în fiecare an, în februarie, într-o nouă versiune majoră. Fiecare versiune presupune o versiune minimă de PHP și primește timp de aproximativ doi ani remedieri de erori. Potrivit phpunit.de, situația este:
| PHPUnit | Apărut | Cerință PHP | Remedieri de erori până la |
|---|---|---|---|
| 13 | 06.02.2026 | de la PHP 8.4 | 04.02.2028 |
| 12 | 07.02.2025 | de la PHP 8.3 | 05.02.2027 |
| 11 | 02.02.2024 | de la PHP 8.2 | 06.02.2026 |
| 10 | 03.02.2023 | de la PHP 8.1 | 07.02.2025 |
Tabelul arată o legătură practică: un proiect care mai folosește PHPUnit 10 rulează de obicei și pe o versiune PHP veche. Instrumentele de testare și versiunea PHP ar trebui ridicate împreună. PHPUnit se instalează de obicei prin Composer, ca dependență de dezvoltare.
Un prim test cu PHPUnit
Un test este o clasă care moștenește PHPUnit\Framework\TestCase. Metodele de test sunt publice și încep cu test; alternativ, se marchează cu atributul #[Test]. Exemplul verifică o funcție simplă de calcul al prețului:
<?php declare(strict_types=1);
use PHPUnit\Framework\Attributes\DataProvider;
use PHPUnit\Framework\TestCase;
final class BruttopreisTest extends TestCase
{
public static function preise(): array
{
return [
'Normalsatz' => [10000, 19, 11900],
'Ermäßigt' => [10000, 7, 10700],
'Null bleibt Null' => [0, 19, 0],
];
}
#[DataProvider('preise')]
public function testBruttopreisInCent(int $netto, int $satz, int $erwartet): void
{
$this->assertSame($erwartet, bruttopreis($netto, $satz));
}
}
Data provider-ul oferă mai multe cazuri pentru același test. Potrivit documentației PHPUnit, el trebuie să fie public și static. Se calculează în cenți, ca număr întreg, pentru ca numerele în virgulă mobilă să nu producă erori de rotunjire. Suita se rulează cu ./vendor/bin/phpunit, dacă PHPUnit este instalat prin Composer.
Pest: aceeași bază, scriere mai scurtă
Potrivit documentației, Pest este construit pe PHPUnit. Testele se scriu ca funcții cu it() sau test(), iar așteptările cu expect(). Pest 5 presupune PHP 8.4. Instalarea conform documentației:
composer remove phpunit/phpunit
composer require pestphp/pest --dev --with-all-dependencies
./vendor/bin/pest --init
Același test, în scrierea Pest:
<?php
it('berechnet den Bruttopreis zum Normalsatz', function () {
expect(bruttopreis(10000, 19))->toBe(11900);
});
Testele PHPUnit existente sunt convertite în mare parte automat de plugin-ul pestphp/pest-plugin-drift. Ce stil de scriere alege o echipă este o chestiune de gust; decisiv este ca testele să ruleze regulat.
Ce tipuri de teste sunt utile
- Teste unitare: verifică funcții și clase individuale, fără bază de date sau rețea.
- Teste de integrare: verifică conlucrarea cu baza de date, sistemul de fișiere sau interfețele.
- Teste funcționale prin HTTP: accesează pagini și formulare așa cum o face un browser.
- Teste de regresie pentru securitate: rețin erori remediate, de exemplu că ieșirile sunt mascate cu
htmlspecialchars()sau că o autentificare eșuează după o parolă greșită. - Smoke tests după deployment: câteva verificări rapide dacă pagina live răspunde după o actualizare.
Complementar testelor, analiza statică cu PHPStan și Psalm găsește erori fără a executa codul.
Testele ca plasă de siguranță pentru actualizări și PHP2Shell
PHP2Shell a arătat cât de scurt poate fi timpul dintre publicare și presiunea de a acționa: anunț la 20.10.2026, patch-uri la 21.10.2026, nivel de avertizare portocaliu al BSI (German Federal Office for Information Security). Cine avea o suită de teste a putut instala PHP 8.4.27 sau 8.3.36 într-un mediu de test, a rulat testele și a trecut live în aceeași zi. Fără teste, adesea rămânea doar alegerea între o actualizare neverificată și o vulnerabilitate deschisă.
Beneficiul este și mai mare la schimbarea versiunii majore. Pentru PHP 8.1 și mai vechi nu mai există actualizări oficiale, iar PHP 8.2 se încheie la 31.12.2026, așa cum explică pagina Sfârșitul vieții PHP. O rulare de test pe versiunea țintă arată din timp ce funcții depășite trebuie înlocuite. Este rezonabil un pipeline CI care rulează testele pe mai multe versiuni PHP, plus o privire asupra release candidate-urilor precum PHP 8.6.0, dar niciodată în producție.
Scrieți câte un test pentru fiecare eroare de securitate remediată în aplicația dumneavoastră. Astfel vă asigurați că aceeași eroare nu revine la o modificare ulterioară.
Cum ajută PHP SOS concret?
La migrarea de la PHP 8.1 și mai vechi și la actualizările curente vă sprijinim astfel:
- Evaluarea situației existente: Ce teste există, ce versiune PHP și PHPUnit rulează, unde lipsesc testele pentru procesele critice?
- Crearea unei acoperiri minime: Împreună cu echipa dumneavoastră de dezvoltare sau cu agenția, securizăm cu teste autentificarea, formularele și traseele de comandă.
- Testarea actualizărilor: Versiunile noi de PHP rulează mai întâi într-un mediu de test, față de suită.
- Documentarea rezultatului: Primiți rezultatele testelor și versiunile ca dovadă pentru pasul de patch sau de migrare.
Întrebări frecvente
De ce versiune PHPUnit am nevoie?
Depinde de versiunea dumneavoastră de PHP. PHPUnit 13 presupune PHP 8.4, PHPUnit 12 presupune PHP 8.3, iar PHPUnit 11 presupune PHP 8.2. Tabelul actual se găsește pe phpunit.de, la versiunile acceptate.
Este Pest un înlocuitor pentru PHPUnit?
Potrivit propriei documentații, Pest este construit pe PHPUnit și oferă o scriere mai scurtă. Testele PHPUnit existente pot fi convertite în mare parte automat cu plugin-ul Drift, iar unele trebuie adaptate manual.
Ajută testele împotriva vulnerabilităților din PHP însuși?
Nu direct. Vulnerabilități precum PHP2Shell se află în interpretor și se închid printr-o actualizare PHP. Testele fac însă posibilă instalarea rapidă a acestei actualizări, fără teama unor erori neobservate în aplicație.
Câte teste sunt suficiente?
Nu există un număr fix. Este rezonabil să acoperiți mai întâi traseele critice pentru afacere: autentificare, comandă, formulare, interfețe. Apoi acoperirea cu teste crește cu fiecare modificare și cu fiecare eroare remediată.