Tests unitaires, non-régression et recette

Questions fréquentes

C'est quoi un test unitaire ?

Un test unitaire est un petit programme qui vérifie automatiquement le comportement d'une unité de code (une fonction, une méthode) isolée du reste : il l'appelle avec des données choisies et compare le résultat obtenu au résultat attendu. Il ne touche ni la base de données ni le réseau, s'exécute en quelques millisecondes et se relance après chaque modification. Il suit la structure préparer, agir, vérifier (AAA) et se lance avec un framework comme Vitest, xUnit, PHPUnit ou JUnit.

Quelle est la différence entre un test unitaire et un test d'intégration ?

Le test unitaire vérifie une unité isolée ; le test d'intégration vérifie que plusieurs composants fonctionnent ensemble, par exemple une route d'API avec ses middlewares, sa règle métier et la base de données. Le premier trouve les erreurs de logique, le second les erreurs de branchement : un middleware oublié, un format de date différent entre la base et le code. On écrit beaucoup de tests unitaires et moins de tests d'intégration, comme le recommande la pyramide des tests.

C'est quoi un test de non-régression ?

C'est le fait de rejouer, après chaque modification du logiciel, les tests qui passaient avant, pour vérifier que la modification n'a rien cassé dans ce qui fonctionnait. On dit aussi « test de régression » : c'est la même chose. En pratique, la suite de tests automatisés est relancée à chaque commit et dans l'intégration continue, et chaque bug corrigé laisse derrière lui le test qui l'aurait détecté (la méthode).

Qu'est-ce que la pyramide des tests ?

C'est un modèle qui recommande beaucoup de tests unitaires (rapides et précis) à la base, moins de tests d'intégration au milieu, et très peu de tests de bout en bout (lents et fragiles) au sommet. Chaque règle métier se teste au niveau le plus bas possible ; les niveaux du haut vérifient que les morceaux s'assemblent. La forme inverse, avec presque tout testé dans un navigateur, s'appelle le cornet de glace : une suite lente et instable.

Quelle est la différence entre un mock et un stub ?

Les deux sont des doublures de test qui remplacent une dépendance réelle, comme une base de données ou un serveur de courriel. Un stub fournit des réponses préparées : le test vérifie ensuite le résultat du code. Un mock enregistre les appels reçus : le test vérifie que le code l'a appelé comme prévu, par exemple qu'un courriel a été envoyé à la bonne adresse. On utilise un stub quand la dépendance fournit une donnée, un mock quand l'appel est lui-même l'effet attendu.

C'est quoi le TDD ?

Le TDD (Test-Driven Development) est une méthode où l'on écrit le test avant le code, par petits pas : un test qui échoue (rouge), le code minimal qui le fait passer (vert), puis une amélioration du code sans changer son comportement (refactor), comme dans le kata du cours. Elle produit un code entièrement testé et une conception plus simple. Elle s'applique très bien à la correction de bugs : on écrit d'abord le test qui reproduit le bug.

Qu'est-ce qu'un cahier de recette et un rapport de test ?

Le cahier de recette liste les cas de test qui vérifient chaque exigence d'un logiciel : préconditions, étapes, résultat attendu, puis résultat obtenu et statut lors de l'exécution. Le client ou le Product Owner le déroule pendant la recette avant d'accepter la livraison. Le rapport de test rend compte d'une campagne : ce qui a été testé, le nombre de cas réussis et en échec, les anomalies ouvertes et la recommandation de mise en production. Il est attendu à l'E5 et peut être demandé à l'E6.

Vitest ou Jest : quel outil de test choisir en JavaScript ?

Pour un nouveau projet en 2026, Vitest est le plus simple : il gère nativement les modules ES, TypeScript et JSX, sans configuration. Jest reste très répandu dans les projets existants, et son API est presque identique (jest.fn() devient vi.fn()). En C#, on utilise surtout xUnit ; en PHP, PHPUnit ; pour les tests de bout en bout d'une application web, Playwright.

Quelle couverture de code faut-il viser ?

Un seuil de 70 à 80 % des lignes est réaliste pour une application ; viser 100 % pousse à écrire des tests sans intérêt. La couverture montre le code qu'aucun test n'exécute, mais pas la qualité des tests : un test sans vraie vérification couvre le code sans rien prouver. Pour mesurer la qualité des tests sur les modules critiques, on utilise des tests de mutation.

Comment les tests tombent-ils à l'examen du BTS SIO SLAM ?

À l'écrit E7 (U7), le sujet donne souvent une classe de test JUnit ou PHPUnit : il faut expliquer les cas testés, écrire un test d'une méthode ou trouver le cas manquant, en particulier pour un contrôle d'accès. À l'E6, la commission attend des tests automatisés qui tournent dans ton projet, un test pour l'évolution réalisée, la non-régression, et parfois un rapport de test. Jusqu'à la session 2024, l'écrit de cybersécurité s'appelait E6 (U6) : ses sujets restent de bons entraînements.