Niveaux de test
Chaque niveau de test a une intention, un périmètre et des intervenants différents. Les combiner forme la pyramide des tests — une stratégie équilibrée qui maximise la couverture tout en gardant des retours rapides.
01 - Les quatre niveaux
Que fait chaque niveau exactement ?
01
Tests unitaires
Objectif — Vérifier le comportement d'un composant isolé (fonction, classe, module) indépendamment du reste du système.
Qui : Développeurs
Quand : A chaque commit
Le plus bas niveau de la pyramide. Rapides, automatisés et exécutés en continu, ils forment le filet de sécurité de base. Ils s'appuient sur des doublures (mocks, stubs, fakes - des doublures de test (test doubles) utilisés pour remplacer des dépendances réelles (bases de données, API, services externes) afin de tester un composant de façon isolée) pour isoler le code testé de ses dépendances.
FORCES :
-
Très rapides.
-
Localisent précisément les défauts.
-
Documentent l'intention du code.
LIMITES
-
Ne valident pas les interactions.
EXEMPLES
-
JUnit, NUnit, pytest, Jest.
-
Mocks, stubs.
-
TDD :
-
Red : un petit test unitaire qui décrit le comportement attendu d’une fonction ou d’une méthode, mais le code n’existe pas encore.
-
Green : le minimum de code pour que le test passe (sans chercher la perfection).
-
Refactor : améliore le code (meilleurs noms, suppression de duplication, découpage en fonctions, optimisation).
-
Couverture cible : 70-80% des lignes critiques.
02
Tests d'intégration
Objectif — Valider les interactions entre composants ou systèmes : appels API, accès base de données, files de messages, services externes.
Qui : Développeurs & QA
Quand : Après l'unitaire, avant le système.
On distingue l'intégration composant (entre modules d'une même application) et l'intégration système (entre applications ou services). Les stratégies classiques : big bang, top-down, bottom-up, sandwich, incrémental.
FORCES :
-
Valident les échanges réels entre composants.
-
Détectent les problèmes d'interface.
LIMITES
-
Plus lents et plus coûteux que les tests unitaires.
-
Plus complexes à mettre en place et à maintenir.
-
Le diagnostic est parfois moins précis que sur un test unitaire.
EXEMPLES
-
Intégration composant.
-
Intégration système (API >< BDD).
-
Contrat d'interface.
Couverture cible : couvrir les chemins critiques inter-composants.
03
Tests système
Objectif — Évaluer le système complet par rapport aux exigences fonctionnelles et non-fonctionnelles.
Qui : QA
Quand : Après un build stable, sur un environnement stable dédié.
Réalisés en boîte noire sur un environnement représentatif de la production. Ils couvrent les flux de bout en bout, la sécurité, la performance, la compatibilité multi-navigateurs / multi-OS, et le comportement sous charge.
FORCES :
-
Vue globale du produit.
-
Représentatifs de l'expérience utilisateur.
LIMITES
-
Plus lents et coûteux.
-
Plus fragiles (flaky tests).
EXEMPLES
-
Tests de bout en bout.
-
Tests de charge.
-
Tests de sécurité.
Couverture cible : couvrir les scénarios critiques de bout en bout.
04
Tests d'acceptation
Objectif — Confirmer que le système répond aux besoins métier et que l'utilisateur peut l'accepter.
Qui : Utilisateurs/Métier
Quand : Avant la mise en production.
L'ISTQB distingue plusieurs formes : UAT (User Acceptance Testing - Tests d'acceptation), tests contractuels et réglementaires, tests alpha (chez l'éditeur) et bêta (chez de vrais utilisateurs).
FORCES :
-
Validation par le vrai utilisateur.
-
Réduit le risque de rejet.
LIMITES
-
Détecte tardivement les défauts.
-
Dépend de la disponibilité du métier.
EXEMPLES
-
Tests d'acceptation.
-
Tests contractuels.
-
Tests opérationnels.
Couverture cible : couvrir le cas réel d'usage et conformité aux critères d'acceptation.
02 - Stratégies d'intégration
Les stratégies d'intégration.
Comment assembler et tester les composants ? L'ISTQB recense plusieurs approches, chacune avec ses compromis entre rapidité de mise en place et facilité de diagnostic.
Big bang
Tout est intégré d'un coup, puis testé. Simple, mais diagnostic difficile en cas d'échec.
Top-down
On part des modules de haut niveau et on descend, en utilisant des stubs pour les modules inférieurs.
Bottom-up
On commence par les modules bas niveau avec des drivers, puis on remonte vers les couches supérieures.
Sandwich
Combinaison top-down et bottom-up, on se rejoint au milieu. Bon compromis sur les gros systèmes.
Incrémental
On intègre les composants un par un, en validant à chaque étape. Diagnostic facile, mais plus long.
03 - Les schémas à éviter
Les différentes organisations de test à éviter.
Cône de glace
Beaucoup de bout en bout, peu d'unitaires. Suite lente, fragile et coûteuse à maintenir.
Sablier
Beaucoup d'unitaires et de bout en bout, presque pas d'intégration. Les bugs d'interface passent entre les mailles.
Cupcake (anti‑modèle de hiérarchie de tests)
Tout manuel sur le dessus, avec une base importante de tests unitaires. Pas durable dès que le produit grossit.
04 - La pyramide idéale
La pyramide des tests
Théorisée par Mike Cohn, elle propose une répartition saine : beaucoup d'unitaires à la base, moins d'intégration au milieu, peu de BeB (bout en bout) au sommet. L'objectif n'est pas la perfection géométrique, mais l'équilibre entre vitesse, coût et confiance.
BeB / UI
Lents, fragiles et coûteux ; à réserver quelques scénarios critiques
Intégration / API
Valident les contrats et interactions
Unitaires
Rapides, nombreux > fondation de la confiance
05 - A retenir
En bref :
-
Chaque niveau a un objectif et un responsable distincts — ne pas les confondre.
-
Les tests unitaires offrent des retours rapides, les tests d’intégration valident les échanges, les tests système couvrent les parcours complets, et les tests d’acceptation confirment la valeur métier.
-
La pyramide des tests est un repère utile, mais elle doit être adaptée au produit et à ses risques.
-
Un test mal placé (BeB pour ce qui pourrait être unitaire) coûte plus cher. Cela revient à reporter la détection des bugs vers la fin du projet, ce qui amplifie le coût de correction.
-
Qui fait quoi :
