Une plateforme B2B possède 4 000 tests unitaires, 180 tests d’intégration et 90 parcours navigateur. Une modification de taxe casse pourtant l’export comptable, tandis que la suite end-to-end devient rouge pour un sélecteur sans rapport. Le problème n’est pas l’absence d’une pyramide idéale : les preuves sont placées trop loin des risques qu’elles doivent révéler.
Le problème se voit quand l’équipe discute de proportions avant de nommer comportements, frontières et coût du diagnostic. Le test unitaire donne une réponse précise sur une règle isolée ; il ne prouve pas une contrainte SQL. L’end-to-end observe le système assemblé ; il explique rarement vite quelle frontière a rompu.
La thèse est de choisir le niveau le plus bas qui puisse échouer pour la bonne raison, puis de conserver quelques parcours complets comme preuves de câblage. Contre-intuitivement, une majorité de tests unitaires n’est pas toujours souhaitable : un domaine dominé par les contrats externes et les transactions aura besoin de davantage d’intégration réelle.
Dans une démarche de développement web sur mesure, le dosage se construit par capacité. Il associe rapidité, fidélité, stabilité, données et ownership. Le résultat attendu n’est pas un ratio universel, mais une suite qui bloque les ruptures importantes assez tôt et dont chaque échec produit une action compréhensible.
Cette méthode permet de décider quel niveau observe réellement chaque risque, où accepter une preuve plus lente et quand retirer un scénario redondant qui ne facilite plus le diagnostic.
Associer l’invariant au bon niveau de test
Choisir la preuve qui peut invalider la règle
Un invariant de calcul ou de transition doit être testé près du domaine, avec exemples limites et erreurs explicites. Mais si sa validité dépend d’une unicité SQL, d’un verrou ou d’une transaction, un test unitaire ne peut pas suffire. Le niveau résulte de la propriété observée, pas de la classe qui contient le code.
L’équipe formule d’abord ce qui ne doit jamais arriver : total négatif, double facture, accès inter-tenant ou message perdu. Elle identifie ensuite le mécanisme qui empêche l’événement. Une doublure est acceptable pour isoler une décision ; elle devient trompeuse lorsqu’elle remplace précisément le mécanisme protecteur.
Attribuer le verdict d’un test d’intégration
Le développeur explique la frontière et le diagnostic ; le QA lead maintient données et stabilité ; l’expert métier tranche le comportement ; l’exploitation confirme l’état déployé. Le test d’intégration donne une preuve, mais ne décide pas si un changement est volontaire. Une assertion modifiée exige donc un lien vers la décision et les consommateurs touchés.
Lorsqu’un test rouge vient d’un service indisponible, le pipeline le classe différemment d’une rupture de contrat. L’équipe ne relance pas jusqu’au vert. Elle conserve requête, réponse nettoyée, version et fixture, puis choisit réparation, quarantaine bornée ou blocage selon la conséquence non prouvée.
Capitaliser les défauts sans accumuler les tests
Chaque incident corrigé indique comportement, donnée minimale, cause, niveau de test retenu et raison de ce choix. Le journal relie la preuve au commit sans recopier toutes les étapes. Il permet de vérifier qu’un défaut ancien ne réapparaît pas et d’identifier les zones où plusieurs tests couvrent artificiellement le même cas.
La fixture est versionnée avec le schéma qu’elle exige. Un test retiré garde sa justification et la preuve qui le remplace. Cette traçabilité évite que la pyramide se déforme par accumulation, jusqu’à devenir lente sans mieux protéger le produit.
Ordonner le scénario end-to-end sans double effet
Le parcours crée ses propres données, utilise une clé de corrélation et observe l’état durable avant de conclure. Il ne dépend pas du scénario précédent. Pour une action asynchrone, l’attente interroge une condition bornée plutôt que de dormir un nombre arbitraire de secondes.
Le cas de retry vérifie qu’un timeout après effet ne recrée ni paiement ni commande. Les systèmes externes sont simulés pour provoquer le résultat inconnu, puis quelques contrats sont vérifiés contre leur implémentation. L’end-to-end prouve le câblage complet ; l’idempotence reste aussi testée à la frontière transactionnelle, où son diagnostic est plus court.
Contrôler les angles morts d’une couverture élevée
Comparer la carte de risques au portefeuille
Une couverture de lignes indique du code exécuté, pas une conséquence vérifiée. L’équipe prend cinq flux critiques et cherche nominal, limite, autorisation, panne avant effet, panne après effet et reprise. Chaque trou reçoit la preuve la moins coûteuse capable de l’observer.
Par exemple, un remboursement peut avoir beaucoup de tests unitaires sur son calcul tout en ignorer la transaction avec l’avoir et l’export comptable. Le pilote ajoute une intégration sur les contraintes et un parcours complet sur un paiement mixte. Il ne transforme pas toutes les combinaisons en navigateur.
Piloter avec les zones critiques couvertes
Mesurer le risque et le diagnostic
Le tableau suit invariants critiques avec preuve, défauts échappés, durée avant signal, temps de diagnostic, relances et quarantaines. Un ratio unitaire/intégration/end-to-end n’est pas un objectif. Deux capacités peuvent présenter des distributions différentes parce que leurs risques se trouvent dans des couches différentes.
Les seuils sont locaux. Une boucle de merge peut viser moins de huit minutes sur l’infrastructure observée tandis que les parcours complets terminent avant le déploiement. Si une preuve critique sort de cette fenêtre, l’équipe parallélise ou la déplace sans retirer la propriété observée.
Rendre les échecs reproductibles et tester le repli
Rendre l’échec reproductible hors du pipeline
PHPUnit publie groupe, seed éventuel, fixture et première cause utile. Les intégrations consignent versions de base et de contrat ; l’outil E2E ajoute navigateur, artefact et corrélation. Les sorties ne contiennent ni secret ni donnée personnelle. Une commande locale ou un conteneur reproduit le cas avec les mêmes dépendances utiles.
Le rollback n’est pas une fonction de PHPUnit. La recette crée une donnée avec la nouvelle version, déploie l’ancienne ou désactive le flag, puis vérifie lecture et effets asynchrones. Le runbook précise seuil d’arrêt, migration compatible et marche avant si le retour est impossible. Les tests automatisent les préconditions sans prétendre remplacer la décision d’exploitation.
Faire valider la promesse par le product owner
Le product owner rejoue les décisions et conséquences, pas les détails du framework. Il reçoit exemples avant/après, rôles, états et résultat attendu. Cette recette confirme que les assertions expriment la promesse et non une interprétation technique accidentelle.
Les opérations exécutent séparément panne et reprise. Le product owner accepte une règle ; il ne doit pas manipuler une file ou un rollback. Cette séparation corrige l’ambiguïté du processus tout en gardant une preuve commune reliée au même identifiant de scénario.
Pour qui adapter le dosage des tests
Le dosage concerne toute équipe qui maintient règles, persistance et intégrations. Le responsable sécurité intervient sur autorisation, données sensibles et frontières de confiance, mais ne possède pas la pyramide. Produit, QA, développement et exploitation répartissent ensemble les preuves selon leurs conséquences.
Un service de calcul pur peut rester dominé par l’unitaire ; un workflow transactionnel exige davantage d’intégration ; une interface critique conserve quelques end-to-end. Le choix s’applique par capacité et évolue après incident, nouveau consommateur ou changement d’infrastructure.
Doser les niveaux selon le type de risque
Isoler les décisions déterministes
Les tests unitaires conviennent aux calculs, transitions et politiques dont les entrées et sorties peuvent être rendues explicites. Ils couvrent valeurs limites, combinaisons de règles et propriétés comme la conservation d’un total. Leur vitesse autorise beaucoup d’exemples. En revanche, simuler l’ORM, le moteur de requête ou le sérialiseur fabrique souvent une seconde implémentation qui partage les hypothèses du code.
Un bon test unitaire nomme un comportement et ne dépend ni de l’ordre d’exécution ni de l’horloge réelle. Le temps, l’aléatoire et les identifiants sont injectés quand ils influencent la décision. Cette isolation réduit le bruit, sans prétendre que l’intégration finale fonctionnera. Les ports critiques reçoivent ensuite une preuve distincte avec l’adaptateur réel.
Éprouver les frontières réelles
Les tests d’intégration vérifient schémas, contraintes, transactions, mapping, autorisation et contrats réseau. Une base éphémère proche de la version de production révèle des comportements qu’une collection en mémoire ignore. Les dépendances tierces utilisent un sandbox lorsqu’il reproduit le contrat utile, ou un stub gouverné par des exemples capturés et une vérification régulière.
Par exemple, le calcul d’une remise se prouve en unité, son enregistrement concurrent se vérifie avec la base réelle et un unique parcours navigateur confirme que l’utilisateur autorisé voit le montant puis engage la commande. Répéter toutes les combinaisons dans le navigateur allongerait le feedback sans révéler une propriété supplémentaire.
L’end-to-end reste réservé aux parcours dont le câblage complet mérite un verdict : authentification, commande, validation critique, reprise visible. Il vérifie quelques décisions à travers l’interface et les services déployés, sans recopier toutes les variantes déjà couvertes plus bas. Des attributs stables remplacent les sélecteurs liés au style ; les données sont créées par API ou fixture traçable.
Cas concret hypothétique. Un portail de commandes applique une remise, réserve un stock puis publie un événement. L’équipe garde douze exemples unitaires pour arrondis et plafonds, quatre intégrations PostgreSQL pour unicité et transaction, deux contrats sur le schéma d’événement, puis un parcours navigateur qui crée et annule une commande. Une panne injectée après la réservation prouve que le retry ne réserve pas deux fois. Cette distribution vient des mécanismes observés, pas d’un ratio prédéfini.
Le même flux peut changer de dosage. Si un nouveau consommateur exige une compatibilité sur trois versions d’événement, alors les tests de contrat augmentent sans multiplier les end-to-end. Si la base remplace une contrainte applicative, une preuve d’intégration devient prioritaire. L’arbitrage conserve toujours rapidité du signal, fidélité de la frontière et coût de diagnostic ; aucune couche ne gagne par principe.
Une revue trimestrielle prend un défaut échappé et un test instable. Elle demande si le niveau retenu pouvait réellement voir le mécanisme, si la fixture représentait la donnée et si le rouge conduisait à une action. Le portefeuille évolue selon ces faits. Un scénario peut descendre vers l’intégration pour gagner en diagnostic, tandis qu’un nouveau risque de câblage peut justifier un parcours complet supplémentaire.
Gouverner la vitesse et la stabilité
Établir un budget de feedback local
Le dosage se valide par le service rendu. Sur un projet donné, l’équipe peut viser localement une boucle de merge sous sept minutes, une suite d’intégration sous quinze minutes et quelques end-to-end parallélisés dans la fenêtre de livraison. Ces valeurs ne sont ni des standards ni des promesses universelles : elles dépendent de l’infrastructure, du volume et du temps disponible pour corriger avant mise en production.
Le pipeline publie durée médiane et haute, instabilité, relances, défauts échappés et temps de diagnostic par couche. Si un scénario navigateur ne détecte jamais seul un défaut, il descend vers une intégration plus précise ou disparaît. Si une transaction rompt malgré des tests unitaires complets, la frontière gagne une preuve réelle. Le portefeuille évolue avec les incidents et non avec un quota figé.
S’appuyer sur les contrats officiels
La documentation Symfony consacrée aux tests distingue unités, intégration du kernel et tests applicatifs ; elle fournit des mécanismes, pas un ratio métier. De même, PHPUnit décrit fixtures, doubles et attributs, mais le projet reste responsable de la fidélité de chaque preuve.
La quarantaine est une exception gouvernée. Elle porte un owner, un incident lié, une compensation et une date d’échéance. Un test instable relancé jusqu’au vert n’est plus un contrôle : il injecte du hasard dans la décision. Tant que sa cause n’est pas réparée, le risque reste visible et peut imposer une recette ciblée ou un déploiement limité.
Éviter les erreurs fréquentes de dosage
Appliquer un ratio universel
Viser mécaniquement une proportion ignore où vivent les risques. Le portefeuille est lu par capacité et par propriété. Un écart au dessin idéal n’est pas une dette si vitesse, fidélité et diagnostic répondent au besoin.
Mocker la frontière protectrice
Une base simulée ne prouve pas l’unicité, un faux sérialiseur ne prouve pas le contrat et un bus en mémoire ne prouve pas la transaction. Les doublures servent à provoquer des réponses rares ; les mécanismes critiques restent exécutés dans une intégration dédiée.
Répéter le même cas à tous les niveaux
La redondance augmente maintenance et faux rouges sans renforcer la preuve. Les unitaires détaillent décisions, les intégrations les frontières, les end-to-end le câblage. Un scénario complet ne répète que les quelques invariants nécessaires à sa confiance.
Arbitrer avec le scénario de panne
Une matrice compare conséquence, mécanisme réel, coût d’exécution, stabilité, diagnostic et fréquence. La panne choisie doit pouvoir invalider l’hypothèse : concurrence pour l’unicité, timeout après effet pour l’idempotence, ancien consommateur pour la compatibilité. Le niveau qui observe l’échec avec le moins de dépendances devient la preuve principale.
Un end-to-end reste justifié si seul le système assemblé révèle le défaut, par exemple cookie, proxy et droit. Il est retiré lorsqu’une intégration plus stable couvre la même rupture et qu’un parcours plus large prouve déjà le câblage. Cette décision est documentée avec le cas remplacé.
Plan d’action : sécuriser l’invariant métier et décider l’extension
D’abord, inventorier les propriétés critiques
L’équipe sélectionne cinq capacités et écrit invariants, frontières, données limites, droits et reprises. Elle rapproche incidents et tests existants, identifie les mocks placés sur les mécanismes protecteurs et mesure durée comme diagnostic. Aucun ratio n’est fixé avant cette lecture.
Ensuite, redistribuer les scénarios
Les décisions pures descendent vers l’unitaire ; transactions, sérialisation et contrats rejoignent l’intégration ; quelques parcours gardent l’assemblage. Les doublons sont retirés après preuve d’équivalence. Fixtures et horloge deviennent déterministes, tandis que les dépendances réelles restent présentes là où elles comptent.
Puis, provoquer les exceptions
La recette joue concurrence, timeout avant et après effet, ancienne version, droit retiré et dépendance indisponible. Chaque résultat doit produire une action sûre. Le support reproduit sans modification directe ; l’exploitation vérifie rollback ou marche avant. Une quarantaine reçoit compensation et date de réparation.
Enfin, maintenir le dosage
La revue suit défauts échappés par capacité, temps avant signal, diagnostic et instabilité. Un nouveau contrat ou incident peut déplacer le dosage. L’extension vers un flux supplémentaire attend que le portefeuille actuel reste compréhensible, que les propriétaires répondent et qu’une personne non auteure sache exécuter la reprise.
- D’abord, nommer l’invariant et le mécanisme qui le protège.
- Ensuite, choisir le niveau le plus bas qui observe sa rupture.
- Puis, tester données limites, panne et reprise avec les vraies frontières.
- Enfin, réviser le dosage selon les défauts et le coût de diagnostic.
Guides complémentaires pour fiabiliser l’invariant métier
Choisir l’outil après la propriété
La documentation de test Symfony décrit les outils unitaires, kernel, client et navigateur. Elle fournit des mécanismes ; la carte de risques indique lequel garde la frontière utile.
Pour des exécutions reproductibles, la documentation PHPUnit 11.5 précise suites, groupes et fixtures. Le projet y ajoute ses conventions de données, parallélisme et quarantaine.
Relier le test au run
L’observabilité des workflows permet de rapprocher l’identifiant d’un scénario et la chronologie déployée. Une preuve d’intégration reste ainsi utile pendant l’incident.
Les scénarios qui traversent une migration suivent le guide Symfony de compatibilité du run avant d’être considérés comme repliables.
- Faire correspondre règle pure, frontière réelle et parcours assemblé.
- Conserver une commande reproductible pour chaque niveau.
- Vérifier les données nouvelles sur la version précédente.
Conclusion : doser selon le signal recherché
Les tests unitaires, d’intégration et end-to-end ne sont pas trois camps. Ils répondent à des questions différentes : la décision isolée est-elle correcte, la frontière réelle tient-elle son contrat, le système assemblé permet-il le parcours attendu ? Le bon dosage minimise la distance entre le défaut et sa preuve, tout en conservant quelques contrôles de bout en bout.
Commencez par une capacité critique, classez ses risques et déplacez chaque scénario vers la couche la plus précise. Mesurez ensuite délai de feedback, instabilité et défauts échappés avant d’étendre.
Dawap peut vous accompagner pour structurer ce portefeuille, son pipeline et ses données de reprise dans une application web sur mesure, afin que la suite reste rapide, fidèle et maintenable par l’équipe qui exploite le produit.
