Le test unitaire vérifie une à une les plus petites parties fonctionnelles d’un programme, avant qu’elles ne soient assemblées en fonctionnalités. Les développeurs écrivent chaque test unitaire sous la forme d’un court morceau de code qui s’exécute automatiquement en quelques secondes. Comme chaque test examine une seule partie de façon isolée, un échec désigne directement le code défaillant.
De toutes les vérifications qu’un produit traverse avant sa sortie, le test unitaire est celle qu’une équipe QA n’exécute généralement pas, car ce travail revient aux développeurs. Une fois que chaque unité se comporte correctement, l’automatisation de la QA peut se concentrer sur ce que les tests unitaires ne voient pas : la manière dont les parties fonctionnent ensemble dans de vraies fonctionnalités.
Qu’est-ce que le test unitaire et que vérifie-t-il ?
L’International Software Testing Qualifications Board (ISTQB) définit le test unitaire comme un niveau de test qui évalue la plus petite partie de code testable de manière isolée. Dans la plupart des programmes, cette partie est une fonction, c’est-à-dire un court bloc de code qui reçoit des données en entrée et renvoie un résultat.
L’isolement consiste à séparer l’unité de la base de données, du prestataire de paiement et du service de connexion. Les développeurs coupent ces liens avec des substituts appelés mocks et stubs : de simples imitations de services externes qui donnent toujours la même réponse. Ainsi, le test n’échoue que lorsque l’unité elle-même pose problème.
Prenons l’exemple d’une boutique en ligne qui accorde 10 % de remise sur tout achat de plus de 100 €. Un test de la fonction de remise pourrait soumettre une commande de 150 € et vérifier que le total obtenu est bien de 135 €. Un deuxième test pourrait essayer exactement 100 € pour contrôler la limite de la règle. Un troisième pourrait envoyer un montant négatif pour s’assurer que le code rejette cette saisie. Les trois tests se terminent presque instantanément, sans panier, sans client et sans page de paiement.
L’isolement a toutefois une limite : le test unitaire ne peut pas vous dire si les parties fonctionnent ensemble. Par exemple, la fonction de remise peut réussir tous les tests alors que la page de paiement affiche toujours le prix plein.
Qui écrit les tests unitaires ?
Les développeurs écrivent et maintiennent les tests unitaires dans le même projet que le code du produit. Pour ce travail, chaque programmeur s’appuie sur un framework de test, une boîte à outils prête à l’emploi pour écrire et lancer des vérifications. Parmi les exemples courants figurent JUnit pour Java, pytest pour Python et Jest pour JavaScript. Chaque test unitaire s’exécute d’abord sur l’ordinateur du développeur. Le même test est ensuite relancé dans le pipeline de CI (intégration continue), un système automatisé qui reconstruit et vérifie le produit après chaque modification du code.
La rapidité du retour est l’une des raisons pour lesquelles ce travail revient aux développeurs. Une suite de tests bien construite, c’est-à-dire l’ensemble complet des tests unitaires d’un produit, se termine en quelques minutes. Cette vitesse permet au programmeur de corriger une erreur pendant que le code est encore frais dans son esprit. L’autre raison est que l’écriture de ces tests implique de lire et de modifier le code du produit, ce qui fait partie du travail quotidien des développeurs.
Les ingénieurs QA ont malgré tout un rôle à jouer dans le test unitaire. Chez QAwerk, nous passons en revue les tests unitaires avec les développeurs qui les écrivent et nous listons les situations qu’aucun test ne couvre encore, par exemple un champ de formulaire vide, une commande inhabituellement importante ou une connexion internet perdue. Une fois que de nouveaux tests existent pour ces lacunes, une exécution réussie montre que le code les gère aussi.
Quelle place occupe le test unitaire dans la pyramide des tests ?
De nombreuses équipes logicielles organisent leurs vérifications selon la pyramide des tests, un schéma qui classe les tests par taille et par vitesse. Les tests unitaires en forment la large base, car ce sont les moins coûteux à écrire et les plus rapides à exécuter. Un produit peut donc facilement en compter des milliers. Les tests d’intégration se situent au milieu et vérifient comment des parties distinctes fonctionnent ensemble. Au sommet étroit, les tests de bout en bout suivent un parcours utilisateur complet, par exemple l’inscription puis le paiement d’un abonnement.
La forme de la pyramide reflète le coût. Un test unitaire s’exécute en quelques secondes, alors qu’un achat scripté dans un vrai navigateur peut prendre plusieurs minutes. Cette exécution plus longue peut aussi échouer pour des raisons sans rapport avec le code, comme un signal Wi-Fi faible. Les équipes réservent donc les lents passages en navigateur aux parcours utilisateur complets et testent les règles et les connexions individuelles dans les couches inférieures.
La plupart des projets logiciels passent par quatre niveaux de test standard, dans cet ordre : unitaire, intégration, système et acceptation. Les tests de bout en bout s’exécutent généralement pendant les deux derniers, une fois le produit entièrement assemblé. Notre guide sur les phases du test logiciel présente les quatre en détail.
Test unitaire vs test d’intégration vs test de bout en bout
Les tests unitaires, d’intégration et de bout en bout forment les trois couches de la pyramide. C’est pourquoi ces termes reviennent le plus souvent dans les plans de projet et les rapports d’avancement. Chaque type détecte une catégorie de problème différente. Cette différence compte lorsque vous lisez un rapport : « tous les tests unitaires passent » confirme que chaque morceau de code couvert fonctionne seul, mais ce résultat ne montre pas encore qu’un client peut finaliser un achat. Le comparatif ci-dessous montre aussi pourquoi les équipes limitent au minimum les vérifications de bout en bout et s’appuient sur les couches inférieures pour l’essentiel du détail.
Ce qui est vérifié
Une fonction ou un petit morceau de code
Une connexion entre des parties ou des services
Un parcours utilisateur complet
Exemple typique
La règle de mot de passe refuse tout ce qui fait moins de 8 caractères
Un paiement réussi met à jour le statut de la commande
Un client cherche dans le catalogue, paie une veste et reçoit un e-mail de confirmation
Qui écrit généralement les tests
Les développeurs
Les développeurs et les ingénieurs QA
Les ingénieurs en automatisation QA
Durée d’un test
Quelques secondes au plus
Jusqu’à une minute
Plusieurs minutes
Ce qu’indique un échec
Exactement quelle fonction a cassé
Quelle connexion a cassé
Qu’un parcours est cassé, mais rarement où
Bonnes pratiques du test unitaire : à quoi ressemblent de bons tests
Les bonnes pratiques du test unitaire ci-dessous sont aussi des questions à poser à vos développeurs :
- La suite de tests complète se termine-t-elle en quelques minutes ? Les développeurs ont tendance à sauter les exécutions lentes, et une vérification sautée ne détecte rien.
- Chaque test se limite-t-il à un seul comportement ? Ainsi, un échec nomme le problème en termes simples, par exemple « refuse une adresse e-mail vide ».
- Les tests évitent-ils les services externes réels ? Les vérifications qui appellent une vraie base de données ou un vrai prestataire de paiement échouent dès que ces systèmes sont lents. Après suffisamment de fausses alertes, les équipes finissent par ignorer complètement les échecs.
- Les cas d’erreur sont-ils testés ? Les bugs graves se cachent souvent dans le code qui traite les saisies incorrectes. Une fonction qui lit une date de naissance a besoin de tests pour un champ vide et un mauvais format, en plus du cas ordinaire.
- La couverture est-elle un repère ou un objectif ? La couverture de code est la part d’un programme que les tests exécutent réellement. Un faible pourcentage signale des zones non testées. Un pourcentage élevé prouve toutefois peu de chose à lui seul, car un test peut exécuter une ligne de code sans en vérifier le résultat.
- La suite s’exécute-t-elle à chaque modification ? Le pipeline de CI doit lancer les tests automatiquement et empêcher toute mise à jour qui provoque un échec d’atteindre la version principale du produit.
- Qui relit les tests écrits par l’IA ? Les outils d’IA peuvent désormais écrire des tests unitaires en quelques secondes, ce qui fait gagner un temps réel. Pourtant, lorsque Meta a étudié un générateur de tests interne, les ingénieurs ont accepté 73 % des tests proposés et ont rejeté les autres après relecture. Un programmeur ou un spécialiste QA doit donc approuver chaque test généré avant qu’il n’intègre la suite.
Quel rôle joue la QA aux côtés du test unitaire ?
Des tests unitaires solides changent l’objet du travail d’une équipe QA. Quand la logique de base est déjà couverte, les testeurs trouvent moins d’erreurs simples, comme un total erroné ou un format de date cassé. Les ingénieurs QA peuvent alors se concentrer sur les problèmes que le test unitaire ne voit pas, qui apparaissent entre les parties du produit et face aux vrais utilisateurs :
- Comment les parties fonctionnent ensemble : les tests d’intégration vérifient les connexions, par exemple si une réservation confirmée envoie bien un e-mail au client. Pour les produits liés à des fournisseurs externes et à des plateformes partenaires, les tests d’intégration système couvrent aussi ces liens.
- Si les anciennes fonctionnalités marchent encore : les tests de régression relancent les vérifications précédentes après chaque mise à jour, car une modification à un endroit peut casser une fonctionnalité ailleurs.
- Le ressenti à l’utilisation : les tests manuels menés par un spécialiste expérimenté repèrent les écrans déroutants et les comportements étranges. Une partie de ce travail relève du test exploratoire, une investigation libre du produit sans script préparé.
Avec les tests unitaires, ce travail compose le test de la qualité logicielle, où chaque type de vérification détecte des problèmes que les autres manquent. Nos ingénieurs partent des tests que vos développeurs ont déjà écrits et construisent par-dessus une couverture automatisée et manuelle. Ainsi, aucun travail n’est fait en double et rien ne passe entre les mailles du filet.
Vous voulez trouver les lacunes que vos tests unitaires laissent passer ? Parlez à notre équipe.
Questions fréquentes
Le test unitaire est-il la même chose que le test de composants ?
Le test unitaire et le test de composants sont souvent confondus, pourtant le glossaire de l’ISTQB, la référence en matière de terminologie QA, donne désormais à chaque terme sa propre définition. La plus petite partie vérifiable d’un programme, généralement une seule fonction, constitue une unité. Un composant peut être plus grand, comme un module de paiement composé de nombreuses pièces plus petites. Même dans ce cas, le test l’isole du reste du système.
La QA écrit-elle des tests unitaires ?
Le test unitaire est généralement le travail des développeurs, car les tests vivent dans le code source du produit et se relancent après chaque modification. Les ingénieurs QA contribuent en passant en revue les tests existants pour repérer les cas manquants et en testant ce que des fonctions isolées ne peuvent pas révéler, comme un lien rompu entre deux systèmes. Sur certains projets, des spécialistes de l’automatisation ayant accès au code écrivent aussi ces tests lorsque les développeurs manquent de temps.
Quelle couverture de tests unitaires suffit ?
Aucun chiffre de couverture ne convient à tous les produits. Viser 100 % signifie faire exécuter chaque ligne de code par au moins un test. Cet objectif est rarement rentable, car l’effort part dans du code trivial juste pour faire bouger le chiffre. Un meilleur objectif de test unitaire est une couverture quasi complète des zones à haut risque, comme les paiements, la tarification, la connexion et les données clients stockées. Des revues régulières doivent ensuite confirmer ce que chaque vérification contrôle réellement.
L’IA peut-elle écrire des tests unitaires ?
Oui, l’IA peut générer des tests unitaires et bien gérer le travail répétitif, comme lister des dizaines de variantes d’entrée pour une fonction. Son point faible est l’intention métier. Un modèle d’IA lit le code existant au pied de la lettre : si un bug s’y trouve, le test généré peut le figer comme comportement attendu. Chaque test écrit par l’IA a toujours besoin d’une personne pour confirmer qu’il correspond à ce que veut l’entreprise.
Découvrez comment nous avons aidé ChitChat à corriger plus de 200 bugs sur 24 appareils réels avant sa première sortie en boutique
