Les types de tests et la pyramide des tests

On classe les tests selon trois questions : quelle taille de logiciel ils vérifient (une fonction, plusieurs composants, l'application entière), quoi ils vérifient (une fonctionnalité, la performance, la sécurité) et qui les écrit (le développeur, l'équipe, l'utilisateur). Les tests unitaires, d'intégration, de bout en bout, de non-régression et d'acceptation ne sont pas concurrents : chacun attrape des défauts que les autres laissent passer. La pyramide des tests dit dans quelles proportions les combiner.

Les niveaux de test : du plus petit au plus grand

Le test unitaire

Un test unitaire vérifie le comportement d'une petite unité de code, isolée du reste : il ne touche ni la base de données, ni le réseau, ni le disque, ni l'horloge réelle. Il s'exécute en quelques millisecondes et, quand il échoue, il désigne une fonction précise. C'est le test que tu écriras le plus souvent ; les chapitres 3 à 6 lui sont consacrés.

test('refuse un prêt de 16 jours', () => {
  const demande = { materiel: 'VP-02', debut: '2027-03-15', fin: '2027-03-30' };
  expect(verifierReservation(demande, [], '2027-03-08').motif).toBe('Un prêt dure au plus 15 jours.');
});

Le test d'intégration

Un test d'intégration vérifie que des composants qui marchent séparément marchent aussi ensemble. Les défauts d'intégration sont nombreux et sournois : une route qui oublie le middleware d'authentification, une requête SQL qui renvoie les dates dans un autre format que celui attendu par le code, un nom de champ JSON différent entre l'API et le front. Chaque morceau a ses tests unitaires verts, et pourtant l'ensemble ne marche pas. Le chapitre 8 montre comment tester une API Express avec Supertest.

test('renvoie 409 quand le matériel est déjà réservé', async () => {
  const reponse = await request(app)
    .post('/api/reservations')
    .set('Authorization', 'Bearer jeton-julie')
    .send({ materiel: 'PC-07', debut: '2027-03-12', fin: '2027-03-18' });

  expect(reponse.status).toBe(409);
});

Le test de bout en bout

Un test de bout en bout (end-to-end, E2E) pilote l'application entière comme le ferait un utilisateur : un vrai navigateur ouvre la page, remplit le formulaire, clique sur le bouton et vérifie ce qui s'affiche. Il traverse toutes les couches : front React, API, base de données. C'est le test le plus réaliste, mais aussi le plus lent (plusieurs secondes), le plus fragile (un libellé de bouton change et il casse) et le plus difficile à diagnostiquer (quand il échoue, le défaut peut être n'importe où). Le chapitre 9 l'écrit avec Playwright.

Fonctionnel ou non fonctionnel

Les niveaux disent à quelle échelle on teste. Les types disent quoi :

Le mot « test fonctionnel » désigne aussi, dans beaucoup d'équipes, un test qui vérifie une fonctionnalité du point de vue de l'utilisateur, sans regarder le code : il se situe alors entre le test d'intégration et le test de bout en bout. Ne t'arrête pas aux étiquettes, qui varient d'une entreprise à l'autre : demande-toi ce que le test vérifie et à quelle échelle. Les tests de performance et de sécurité ont leur chapitre 13.

Le test de non-régression

Une régression est une fonctionnalité qui marchait et qui ne marche plus après une modification. Le test de non-régression consiste à rejouer, après chaque modification, les tests qui passaient avant, pour vérifier que rien n'a été cassé. Ce n'est pas un niveau de plus : ce sont tes tests unitaires, d'intégration et de bout en bout, relancés systématiquement. On ajoute aussi, après chaque bug corrigé, le test qui l'aurait détecté. Le chapitre 11 donne la méthode.

Le test d'acceptation et la recette

Le test d'acceptation vérifie que le logiciel répond au besoin exprimé, et pas seulement qu'il fonctionne. En France, on parle de recette : le client (la maîtrise d'ouvrage, MOA) ou le Product Owner déroule un cahier de recette, des cas de test tirés des exigences ou des critères d'acceptation des user stories, puis prononce la réception dans un procès-verbal. En anglais, on parle d'user acceptance testing (UAT). Deux variantes existent pour les logiciels diffusés largement : le test alpha, par des utilisateurs dans les locaux de l'éditeur, et le test bêta, par des utilisateurs réels chez eux, sur une version presque finie. Le chapitre 14 montre comment rédiger un plan de test et un cahier de recette.

Le test de fumée

Un test de fumée (smoke test) est une vérification très rapide, juste après un déploiement, que l'essentiel fonctionne : l'application démarre, la page d'accueil répond, la connexion à la base marche. L'expression vient de l'électronique : on allume l'appareil et on vérifie qu'il ne fume pas. S'il échoue, inutile de lancer les autres tests : on revient à la version précédente.

# Test de fumée de la recette de Prêt'Matos : l'API répond-elle ?
curl --fail --silent https://recette.pretmatos.example/api/sante

Boîte noire et boîte blanche

Les deux approches se complètent : la boîte noire trouve les cas que le développeur n'a pas codés (une règle oubliée), la boîte blanche trouve les branches du code qu'aucun test n'exécute. La couverture de code (chapitre 12) mesure ce second point.

Test statique et test dynamique

Tous les tests vus jusqu'ici exécutent le code : ce sont des tests dynamiques. Les tests statiques examinent le code ou les documents sans les exécuter :

• la revue de code, quand un collègue relit ta pull request (Git et GitHub) ;
• l'analyse statique : un linter comme ESLint, le vérificateur de types de TypeScript ou du compilateur C#, un outil d'analyse de sécurité (SAST) ;
• la relecture d'une spécification ou d'une user story, qui trouve les ambiguïtés avant même d'écrire le code.

Un test statique est souvent le moins cher de tous : ESLint signale une variable inutilisée ou un await oublié avant que tu lances quoi que ce soit.

La pyramide des tests

Combien écrire de tests de chaque niveau ? La pyramide des tests, popularisée par Mike Cohn dans les années 2000, répond par une image : une large base de tests unitaires, une couche plus fine de tests d'intégration, une pointe de tests de bout en bout.

Pourquoi cette forme ? Parce que les tests du bas sont rapides, stables et précis : mille tests unitaires tournent en une seconde, et celui qui échoue désigne la fonction fautive. Les tests du haut sont réalistes mais lents et fragiles : un test de bout en bout qui échoue peut venir du front, de l'API, de la base ou d'un réseau lent. On vérifie donc chaque règle métier en détail en bas, et on garde le haut pour quelques parcours essentiels, comme « réserver un matériel » et « enregistrer une sortie ».

Pour les applications front-end, Kent C. Dodds a proposé en 2018 une variante, le trophée des tests : une base d'analyse statique (ESLint, TypeScript), peu de tests unitaires, beaucoup de tests d'intégration de composants, et quelques tests de bout en bout. L'idée est la même : investir là où le rapport confiance / coût est le meilleur pour ton type d'application. Retiens la règle commune : chaque règle se teste au niveau le plus bas possible, et les niveaux du haut vérifient que les morceaux s'assemblent.

Les tests dans le cycle de vie du projet

Dans un projet mené en cycle en V (gestion de projet), chaque étape de conception, sur la branche descendante, a sa phase de test sur la branche montante. Les tests sont préparés au moment de la conception, même s'ils sont exécutés plus tard.

En agile (Scrum), il n'y a pas de grande phase de test à la fin : chaque user story est testée dans le sprint où elle est développée. La Definition of Done de l'équipe exige en général que les tests automatisés soient écrits et passent, et le Product Owner vérifie les critères d'acceptation de chaque story (user stories et critères d'acceptation). On parle de shift left : déplacer les tests vers la gauche du calendrier, le plus tôt possible.

Qui teste quoi ?

Exercices