# Tester le code PHP : PHPUnit et Pest

> PHPUnit et Pest expliqués : versions, premiers tests, types de tests utiles et pourquoi les tests sécurisent les mises à jour après PHP2Shell.

Source : https://phpsos.de/fr/php/php-testen/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** PHPUnit est l'outil standard pour tester automatiquement le code PHP ; Pest est un framework construit dessus, avec une écriture plus concise. La version actuelle est PHPUnit 13 (depuis février 2026, à partir de PHP 8.4), Pest en est à la version 5. Les tests automatiques ne comblent pas les failles de sécurité de PHP lui-même, mais ils rendent les mises à jour planifiables : après PHP2Shell et avant la fin du support de PHP 8.2 le 31 décembre 2026, c'est l'avantage décisif.

## Pourquoi tester le code PHP ?

Pour la direction, l'intérêt tient en une phrase : les tests rendent les modifications moins chères et plus sûres. Un test automatique vérifie en quelques secondes qu'une fonction fait toujours ce qu'elle doit, par exemple qu'un panier calcule correctement ou qu'une connexion rejette les mauvais mots de passe. Sans tests, c'est un humain qui le vérifie à la main, ou personne.

La différence est particulièrement nette lors des mises à jour. Quand PHP doit être mis à jour à court terme à cause d'une faille critique, de nombreux exploitants hésitent, car ils craignent des erreurs dans la boutique ou le portail clients. Avec une suite de tests, la mise à jour passe d'abord dans un environnement de test, les tests révèlent les problèmes, puis on passe en production.

## PHPUnit : le standard des tests PHP

PHPUnit publie chaque année en février une nouvelle version majeure. Chaque version exige une version minimale de PHP et reçoit environ deux ans de corrections de bogues. Selon phpunit.de :

| PHPUnit | Publiée | Prérequis PHP | Corrections de bogues jusqu'au |
|---|---|---|---|
| 13 | 06/02/2026 | à partir de PHP 8.4 | 04/02/2028 |
| 12 | 07/02/2025 | à partir de PHP 8.3 | 05/02/2027 |
| 11 | 02/02/2024 | à partir de PHP 8.2 | 06/02/2026 |
| 10 | 03/02/2023 | à partir de PHP 8.1 | 07/02/2025 |

Le tableau montre un lien pratique : un projet qui utilise encore PHPUnit 10 tourne généralement aussi encore sur une ancienne version de PHP. Les outils de test et la version de PHP devraient être mis à niveau ensemble. PHPUnit s'installe habituellement via [Composer](https://phpsos.de/fr/php/composer/) comme dépendance de développement.

## Un premier test avec PHPUnit

Un test est une classe qui hérite de `PHPUnit\Framework\TestCase`. Les méthodes de test sont publiques et commencent par `test` ; on peut aussi les marquer avec l'attribut `#[Test]`. L'exemple vérifie une fonction simple de calcul de prix :

```php
<?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));
    }
}
```

Le data provider fournit plusieurs cas pour le même test. Selon la documentation de PHPUnit, il doit être public et statique. Le calcul se fait en centimes, en entier, afin d'éviter les erreurs d'arrondi liées aux nombres à virgule flottante. La suite s'exécute avec `./vendor/bin/phpunit` lorsque PHPUnit est installé via Composer.

## Pest : la même base, une écriture plus concise

Selon la documentation, Pest est construit sur PHPUnit. Les tests s'écrivent sous forme de fonctions avec `it()` ou `test()` et les attentes avec `expect()`. Pest 5 exige PHP 8.4. L'installation selon la documentation :

```bash
composer remove phpunit/phpunit
composer require pestphp/pest --dev --with-all-dependencies
./vendor/bin/pest --init
```

Le même test dans l'écriture de Pest :

```php
<?php
it('berechnet den Bruttopreis zum Normalsatz', function () {
    expect(bruttopreis(10000, 19))->toBe(11900);
});
```

Le plugin `pestphp/pest-plugin-drift` convertit en grande partie automatiquement les tests PHPUnit existants. Le choix de l'écriture est affaire de goût pour une équipe ; l'essentiel est que les tests s'exécutent régulièrement.

## Quels types de tests sont judicieux

1. **Tests unitaires :** vérifient des fonctions et des classes isolées, sans base de données ni réseau.
2. **Tests d'intégration :** vérifient l'interaction avec la base de données, le système de fichiers ou des interfaces.
3. **Tests fonctionnels via HTTP :** appellent pages et formulaires comme le fait un navigateur.
4. **Tests de régression de sécurité :** consignent les erreurs corrigées, par exemple que les sorties sont échappées avec `htmlspecialchars()` ou qu'une connexion échoue après un mauvais mot de passe.
5. **Smoke tests après le déploiement :** quelques vérifications rapides pour savoir si le site en production répond après une mise à jour.

En complément des tests, l'[analyse statique avec PHPStan et Psalm](https://phpsos.de/fr/php/statische-analyse/) trouve des erreurs sans exécuter le code.

## Les tests comme filet de sécurité pour les mises à jour et PHP2Shell

PHP2Shell a montré combien le délai entre la publication et la pression d'agir peut être court : annonce le 20 octobre 2026, correctifs le 21 octobre 2026, niveau d'alerte orange du BSI (office fédéral allemand de la sécurité des technologies de l'information). Qui disposait d'une suite de tests pouvait installer PHP 8.4.27 ou 8.3.36 dans un environnement de test, laisser les tests s'exécuter et passer en production le même jour. Sans tests, il ne restait souvent que le choix entre une mise à jour non vérifiée et une faille ouverte.

L'utilité est plus grande encore lors d'un changement de version majeure. Pour PHP 8.1 et antérieur, il n'y a plus de mises à jour officielles, et PHP 8.2 prend fin le 31 décembre 2026, comme l'explique la page [Fin de vie de PHP](https://phpsos.de/fr/ratgeber/php-end-of-life-risiken/). Une exécution des tests contre la version cible montre tôt quelles fonctions obsolètes doivent être remplacées. Un pipeline CI qui exécute les tests contre plusieurs versions de PHP est judicieux, ainsi qu'un coup d'œil aux release candidates comme PHP 8.6.0, mais jamais en production.

> **Astuce:**
> Écrivez un test pour chaque erreur de sécurité corrigée dans votre application. Vous vous assurez ainsi que la même erreur ne revienne pas lors d'une modification ultérieure.

## Comment PHP SOS aide-t-il concrètement ?

Lors de la [migration depuis PHP 8.1 et antérieur](https://phpsos.de/fr/leistungen/php-migration-legacy/) et lors des mises à jour courantes, nous accompagnons ainsi :

- **Évaluer l'existant :** quels tests existent, quelles versions de PHP et de PHPUnit tournent, où manquent des tests pour les processus critiques ?
- **Établir une couverture minimale :** avec votre équipe de développement ou votre agence, nous sécurisons par des tests la connexion, les formulaires et les parcours de commande.
- **Tester les mises à jour :** les nouvelles versions de PHP passent d'abord dans un environnement de test face à la suite.
- **Documenter le résultat :** vous recevez les résultats des tests et les versions comme preuve de l'étape de correctif ou de migration.


## Questions fréquentes

**De quelle version de PHPUnit ai-je besoin ?**  
Cela dépend de votre version de PHP. PHPUnit 13 exige PHP 8.4, PHPUnit 12 PHP 8.3 et PHPUnit 11 PHP 8.2. Le tableau à jour figure sur phpunit.de, sous les versions prises en charge.

**Pest remplace-t-il PHPUnit ?**  
Selon sa propre documentation, Pest est construit sur PHPUnit et offre une écriture plus concise. Les tests PHPUnit existants peuvent en grande partie être convertis automatiquement avec le plugin Drift ; certains doivent être adaptés à la main.

**Les tests aident-ils contre les failles de sécurité de PHP lui-même ?**  
Pas directement. Des failles comme PHP2Shell se trouvent dans l'interpréteur et se comblent par une mise à jour de PHP. Les tests permettent toutefois d'installer rapidement cette mise à jour, sans craindre des erreurs inaperçues dans l'application.

**Combien de tests faut-il ?**  
Il n'y a pas de nombre fixe. Il est judicieux de couvrir d'abord les parcours critiques pour l'activité : connexion, commande, formulaires, interfaces. Ensuite, la couverture de tests croît à chaque modification et à chaque erreur corrigée.

## Sources

- [PHPUnit](https://phpunit.de/)
- [Pest](https://pestphp.com/)
- [php.net : versions de PHP prises en charge](https://www.php.net/supported-versions.php)