TESTS SYMFONY & QUALITÉ

Des tests qui rendent confiance, pas qui rassurent.

Tests automatisés sur les règles métier, sur les API, et tests de bout en bout dans un vrai navigateur pour les parcours critiques. Analyse statique au niveau maximum, vérification du style. Une chaîne de tests rapide et fiable qui bloque au bon moment — pas 30 minutes plus tard.

§ 01 — Le problème

Le problème.

Sans expert
  • Tests qui rassurent — Couverture haute mais jamais de bug attrapé — les tests copient le code.
  • Tests trop lents — 20 minutes avant de savoir si la livraison est bonne — personne ne les lance en local.
  • Tests instables — Un test échoue deux fois sur dix, personne ne sait pourquoi, tout le monde relance.
  • Pas de tests d'API — Les contrats avec vos partenaires cassent en production, pas avant.
  • Pas de tests de parcours — Les bugs visibles par le client arrivent toujours au moment de la recette.
Avec Vulcain
  • Pyramide claire — des tests métier très rapides
  • Puis fonctionnels
  • Puis d'intégration
  • Puis quelques parcours utilisateurs dans un vrai navigateur. analyse statique au niveau maximum bloquante
  • Jeux de données rejouables
  • Doubles en mémoire pour la vitesse
  • Tests navigateur réservés aux parcours critiques.
§ 02 — Ce qui est livré

Ce qui est livré.

§ 01

Tests sur les règles métier

Tests automatisés sur les règles métier et la coordination applicative, isolés de Symfony et de la base de données par des doubles en mémoire (simulations légères). Chaque règle est vérifiée seule, sans dépendance externe.

  • Règles métier testées
  • Doubles en mémoire
  • Structure claire
  • Écrits en amont du code
§ 02

Tests fonctionnels HTTP

Tests qui tapent la vraie application en HTTP, avec jeux de données rejouables et base dédiée aux tests.

  • Vraies requêtes HTTP
  • Données rejouables
  • Base dédiée aux tests
  • Connexion simulée
§ 03

Tests d'API

Tests qui vérifient les contrats d'API avec vos partenaires ou clients intégrateurs. Contrats stables, aucune surprise en production.

  • Contrats vérifiés
  • Format JSON validé
  • Stabilité garantie
  • Comparaisons contrôlées
§ 04

Parcours utilisateurs

Tests de bout en bout dans un vrai navigateur Chrome, en tâche de fond. Les parcours critiques (commande, paiement, inscription) sont rejoués à chaque mise en production.

  • Vrai navigateur Chrome
  • Scénarios critiques
  • Intégrés à la chaîne
  • Captures en cas d'échec
§ 05

Analyse statique maximum

Analyse automatique au niveau le plus strict, bloquante avant toute intégration. Aucune erreur ne passe en production.

  • Niveau de rigueur maximum
  • Historique maîtrisé
  • Bloquant avant intégration
  • Cas exceptionnels ciblés
§ 06

Chaîne automatisée

Vérification du style, analyse statique, tests, construction, déploiement : tout est automatisé. Aucun code ne rejoint le projet sans feu vert.

  • Style + analyse
  • Tests en parallèle
  • Seuil de couverture
  • Intégration bloquée
tests/Application/Order/PlaceOrderHandlerTest.php php
<?php
declare(strict_types=1);

namespace App\Tests\Application\Order;

use PHPUnit\Framework\TestCase;

final class PlaceOrderHandlerTest extends TestCase
{
    public function test_it_places_an_order_and_publishes_events(): void
    {
        $orders = new InMemoryOrders();
        $stock  = new AlwaysInStock();
        $events = new SpyEventBus();

        $handler = new PlaceOrderHandler($orders, $stock, $events);

        $id = $handler(new PlaceOrder(
            CustomerId::fromString('cust-123'),
            [new OrderItem('SKU-A', 2)],
        ));

        self::assertNotNull($orders->byId($id));
        self::assertCount(1, $events->published('OrderPlaced'));
    }

    public function test_it_rejects_when_stock_insufficient(): void
    {
        $this->expectException(OutOfStock::class);

        (new PlaceOrderHandler(
            new InMemoryOrders(),
            new AlwaysOutOfStock(),
            new SpyEventBus(),
        ))(new PlaceOrder(CustomerId::fromString('c'), [new OrderItem('X', 1)]));
    }
}

Un test d'une règle métier avec des doubles en mémoire — sans base de données, sans framework, sans HTTP. Exécution en millisecondes.

§ 04 — Tarifs & délais
§ 01

Mise en place des tests

2 à 4 semaines · forfait

Introduction d'une pyramide de tests sur une base existante sans tests ou presque.

  • Audit de la testabilité
  • Tests unitaires configurés
  • Tests navigateur configurés
  • Analyse statique au niveau max
  • Intégration bloquante
  • Formation équipe
§ 02

Couverture complète

6 à 12 semaines

Couverture ≥ 80 % sur les règles métier, les API et les parcours critiques, chaîne automatisée verrouillée.

  • Tests des règles métier
  • Tests fonctionnels
  • Tests d'API
  • Parcours navigateur
  • Couverture ≥ 80 %
  • Chaîne complète
§ 03

Coaching tests & qualité

Engagement min. 10 jours

Montée en compétence de votre équipe sur les tests automatisés, les tests navigateur et l'analyse statique. Revue continue.

  • Programmation en binôme
  • Revue de code
  • Atelier test guidé par le test
  • Atelier tests navigateur
  • Facturation au temps passé

Tarifs sur devis après cadrage · forfait ou régie selon le format

§ 05 — Cas client · CRM IoT · 500 bornes supervisées

Cleanbox

Mise en place d'une pyramide de tests complète sur un back-office Symfony de supervision IoT : tests des règles métier, tests navigateur pour les parcours d'exploitation, analyse statique au niveau maximum. Zéro régression critique sur 18 mois d'exploitation.

  • Symfony 6
  • PHPUnit 11
  • Panther
  • Analyse statique max
86 %
Couverture globale
< 45 s
Chaîne complète
0
Incident critique 18 mois
§ 04 — Questions fréquentes

Questions sur les tests & la qualité .

§ 01 Pourquoi l'analyse statique au niveau maximum ?

C'est le niveau le plus strict. Il attrape les erreurs qui passeraient inaperçues en relecture humaine. Coût : +10 % de temps au développement. Gain : moins d'heures de résolution de bugs en production, retour sur investissement très positif sur les projets de plus de 6 mois.

§ 02 Vous testez à 100 % de couverture ?

Non, 100 % est contre-productif. Couverture visée : 90 à 100 % sur les règles métier, 70 à 85 % sur les API, parcours navigateur sur les flux critiques. Total pondéré : 80 à 90 %.

§ 03 Les tests ralentissent le développement ?

Sur les 2 premières semaines, oui. Ensuite non : les tests font gagner du temps car ils permettent de remanier le code sans peur et attrapent les régressions avant la production.

§ 04 Les tests navigateur, c'est vraiment utile ?

Pour les parcours critiques (commande, paiement, inscription), oui — c'est le dernier rempart avant la prod. Ils exécutent un vrai navigateur Chrome en tâche de fond, JavaScript inclus : ils attrapent ce qu'un test purement côté serveur ne voit pas. Pour les écrans internes simples, c'est sur-dimensionné. On cible les 5 à 10 scénarios les plus critiques.

§ 05 Vous écrivez les tests avant le code ?

Sur le métier : oui, quasi-systématiquement. Sur la technique (branchements vers la base, contrôleurs HTTP) : tests après. Ce n'est pas une religion — c'est un outil au bon endroit.

§ 06 Comment vous gérez les jeux de données de test ?

Jeux de données rejouables, base dédiée aux tests, remise à zéro entre chaque test fonctionnel. Chaque test part d'un état propre et prévisible.

§ 06 — Voir aussi
§ 08 — Mettre la forge au travail

15 minutes pour savoir
si on peut forger ensemble.

Un appel, pas un formulaire de 12 champs. Vous m'expliquez votre besoin, je vous dis honnêtement si je suis la bonne personne, on repart avec une prochaine étape claire.

  • 01
    Compte-rendu écrit et estimation envoyés sous 24 h.
  • 02
    Aucun engagement. Aucune relance commerciale.
  • 03
    Si ce n'est pas pour moi, je vous oriente vers un confrère.
symfony