Chapitre 14.2 — Tests fonctionnels (WebTestCase)

Partie 14 : Tests & qualité — Chapitre 2/7 Version de référence : Symfony 7.4.

⏱️ TL;DR

• WebTestCase simule de vraies requêtes HTTP (sans serveur) : static::createClient(), $client->request('GET', '/...'), puis des assertions sur la réponse.
• KernelTestCase (dont hérite WebTestCase) démarre le kernel et donne accès au conteneur (static::getContainer()) pour récupérer des services/le repository.
• Assertions dédiées : assertResponseIsSuccessful(), assertResponseStatusCodeSame(404), assertSelectorTextContains('h1', '…'), assertResponseRedirects('/login').
• Le crawler permet de cliquer des liens et soumettre des formulaires comme un utilisateur.
• Base de test dédiée ; on isole chaque test (rollback via DAMADoctrineTestBundle).
• S’authentifier : $client->loginUser($user).
• Pour un dev Next.js : c’est un test d’intégration façon supertest — on tape des routes et on vérifie le HTML/le statut, sans lancer de serveur réel.

🎯 Objectifs

• Écrire un test fonctionnel qui requête une route et vérifie la réponse.
• Accéder aux services et à la base dans un test.
• Cliquer des liens et soumettre des formulaires.
• Authentifier un utilisateur et isoler la base.

1. KernelTestCase vs WebTestCase

• KernelTestCase démarre le kernel Symfony : on accède au conteneur et donc à tous les services (repository, EntityManager, un service métier). Idéal pour tester une intégration avec la base sans passer par HTTP.
• WebTestCase ajoute un client HTTP simulé : on envoie des requêtes et on vérifie les réponses (statut, HTML, redirection). C’est le test fonctionnel de bout en bout côté serveur.

// tests/Functional/HomeControllerTest.php
use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;
 
final class HomeControllerTest extends WebTestCase
{
    public function testHealthEndpointReturnsOk(): void
    {
        $client = static::createClient();
        $client->request('GET', '/api/health');
 
        self::assertResponseIsSuccessful();                      // 2xx
        self::assertJson($client->getResponse()->getContent());  // c'est du JSON
    }
 
    public function testHomePageShowsTitle(): void
    {
        $client = static::createClient();
        $client->request('GET', '/');
 
        self::assertResponseIsSuccessful();
        self::assertSelectorTextContains('h1', 'BookLab');       // le HTML contient <h1>BookLab</h1>
    }
}

2. Les assertions de réponse

Ces assertions (fournies par le pont Symfony) rendent les tests lisibles et expressifs.

3. Accéder aux services et à la base

Dans un test, on récupère un service via le conteneur de test :

$client = static::createClient();
$repository = static::getContainer()->get(BookingRepository::class);
 
$count = $repository->count([]);
self::assertGreaterThanOrEqual(0, $count);

static::getContainer() donne accès au conteneur (en test, même les services privés sont accessibles). On l’utilise pour préparer des données, vérifier l’état de la base après une action, ou tester un service directement.

4. Cliquer et soumettre (le crawler)

Le crawler simule les interactions d’un utilisateur :

public function testCreateBookingViaForm(): void
{
    $client = static::createClient();
    $crawler = $client->request('GET', '/admin/bookings/new');
 
    // remplir et soumettre le formulaire
    $form = $crawler->selectButton('Réserver')->form([
        'booking[customerEmail]' => 'test@example.com',
        'booking[seats]' => '2',
    ]);
    $client->submit($form);
 
    self::assertResponseRedirects('/admin/bookings');   // POST → Redirect
    $client->followRedirect();
    self::assertSelectorTextContains('.flash-success', 'créée');
}

On peut aussi cliquer un lien : $client->click($crawler->selectLink('Modifier')->link()). C’est un test de bout en bout du parcours (route → contrôleur → formulaire → validation → redirection → flash).

5. Authentifier un utilisateur

Pour tester des zones protégées, on connecte un utilisateur sans passer par le formulaire de login :

$client = static::createClient();
$user = static::getContainer()->get(UserRepository::class)->findOneBy(['email' => 'admin@booklab.test']);
 
$client->loginUser($user);   // simule l'authentification
$client->request('GET', '/admin');
self::assertResponseIsSuccessful();   // l'admin a accès

loginUser() place l’utilisateur dans le contexte de sécurité — pratique pour tester rôles et voters (Partie 10).

6. La base de test et l’isolation

Les tests fonctionnels touchent la base : on utilise une base de test dédiée (environnement test, DATABASE_URL distincte, souvent SQLite ou un schéma séparé). Chaque test doit être isolé : ce qu’un test écrit ne doit pas polluer le suivant.

La solution standard : DAMADoctrineTestBundle, qui enveloppe chaque test dans une transaction et la rollback à la fin — la base revient à son état initial après chaque test, instantanément.

composer require --dev dama/doctrine-test-bundle

⚠️ Piège isolation : sans rollback (ou sans re-création du schéma), les tests fonctionnels s’influencent : un test qui crée une réservation fait échouer un autre qui compte les réservations. C’est la cause n°1 de tests « qui passent seuls mais échouent ensemble » (flaky). DAMADoctrineTestBundle (transaction + rollback par test) règle ça proprement et rapidement. Préparez les données via fixtures (chapitre 14.4), pas en dépendant de l’ordre des tests.

💡 Pour un dev Next.js : WebTestCase ≈ supertest (taper des routes, asserter la réponse) + un crawler pour l’HTML. La grande commodité : loginUser() pour tester l’auth, et getContainer() pour manipuler les services/la base — le tout sans serveur réel (le kernel est monté en mémoire). Rapide et fiable.

✏️ Exercices

Exercice 1. Écrivez un test vérifiant que GET /admin redirige vers le login pour un utilisateur non connecté.

public function testAdminRequiresLogin(): void
{
    $client = static::createClient();
    $client->request('GET', '/admin');
    self::assertResponseRedirects('/login');   // firewall → redirection vers la connexion
}

Exercice 2. Comment tester qu’un admin connecté accède bien à /admin ?

Exercice 3. Vos tests fonctionnels « passent seuls mais échouent quand on lance toute la suite ». Cause probable et solution ?

🧠 Quiz de révision

Prochain chapitre : 14.3 — ApiTestCase — tester l’API (statuts, JSON, sécurité).