Tests unitaires et tests end-to-end : définitions claires

Tests unitaires : la définition simple

Un test unitaire, c'est un morceau de code que les développeurs écrivent pour vérifier qu'une seule unité du programme se comporte comme prévu. Le plus souvent, cette unité est une fonction ou une méthode. On lui fournit une entrée connue, puis on contrôle que la sortie correspond au résultat attendu. Ça colle ? Le test passe. Sinon, il échoue et pointe l'endroit exact du problème.

Ces vérifications sont automatisées. Une fois écrits, les tests se relancent en quelques secondes, autant de fois que nécessaire, sans que personne n'ait à intervenir. Voilà toute la différence avec le réflexe de cliquer sur son site « pour voir si tout marche ». Un humain se fatigue, oublie des cas. Le test, jamais : il contrôle toujours la même chose, de la même façon.

Le terme en anglais : unit tests

En anglais, on dit unit tests ou unit testing. Ce vocabulaire, vous le croiserez partout dans la documentation des outils, puisque la plupart des frameworks de test sont conçus et documentés en anglais. Autre sigle fréquent : TDD, pour Test Driven Development. Le principe ? Écrire les tests avant le code qu'ils doivent vérifier.

Qu'appelle-t-on une unité ?

C'est le plus petit élément de code qu'on peut isoler et tester seul. Sur un site e-commerce, pensez à la fonction qui calcule un prix TTC, à celle qui valide une adresse e-mail ou à celle qui applique un code promo. Retenez surtout ceci : l'unité se teste isolément, sans base de données, sans réseau, sans navigateur. Elle dépend d'un service externe ? On remplace ce service par une imitation, qu'on appelle un mock (ou un bouchon, en bon français).

D'où la rapidité des tests unitaires. Des centaines s'exécutent en quelques secondes. Et quand l'un d'eux tombe, la fonction en cause est identifiée tout de suite, sans fouiller le programme entier.

À quoi servent les tests unitaires dans un projet web

Si vous dirigez une PME, l'intérêt n'est pas technique : il est économique. Un site ou un logiciel bouge sans arrêt (nouvelles fonctionnalités, correctifs, mises à jour de sécurité). Chaque modification peut casser ce qui fonctionnait la veille. Premier rôle des tests unitaires, donc : garantir que ce qui marchait continue de marcher.

Éviter les régressions

Une régression, c'est un bug qui surgit dans une partie du logiciel qui fonctionnait avant une modification. Le cauchemar classique ! On corrige le formulaire de contact et, sans que personne ne s'en aperçoive, le calcul des frais de port se dérègle. Avec une bonne série de tests, l'erreur saute aux yeux avant la mise en ligne. Le développeur la corrige dans la foulée. Mieux vaut ça que de l'apprendre par un client mécontent, non ?

Modifier le code sans crainte

Code non testé, code qu'on n'ose plus toucher : la pente est rapide. Les équipes contournent les zones fragiles, empilent les rustines, et chaque évolution coûte plus cher que la précédente. Des tests fiables inversent la logique. On modifie, on réorganise le code, sereinement. Pour un logiciel métier censé vivre plusieurs années et suivre la croissance de l'entreprise, je considère cela comme non négociable.

Une documentation vivante

Chaque test décrit un comportement attendu : « si le panier dépasse tel montant, la livraison est offerte ». Un nouveau développeur arrive sur le projet ? Il lit les tests et saisit vite les règles métier. Rien à voir avec un document Word qui vieillit dans un coin : cette documentation-là reste à jour, puisque le test échoue dès qu'elle ne correspond plus au code. Elle complète utilement le cahier des charges du logiciel, qui fixe les exigences de départ.

Détecter les erreurs tôt, quand elles coûtent peu

Repérée par un test, sur le poste du développeur, une erreur se corrige en quelques minutes. Découverte en production, la même erreur déclenche une enquête, un correctif en urgence, parfois des commandes perdues. Les tests unitaires ramènent la détection au tout début du processus de développement. Voilà pourquoi de nombreux prestataires sérieux les intègrent dès la conception (et pourquoi je vous conseille de l'exiger du vôtre).

Tests unitaires, tests d'intégration, tests end-to-end : les types de tests

Le test unitaire n'est qu'un étage d'un édifice plus large. En développement logiciel, on distingue plusieurs types de tests selon la taille de ce qu'ils vérifient. Chacun répond à sa propre question. Aucun ne suffit seul.

Les tests unitaires : une pièce à la fois

Une fonction isolée, et rien d'autre : voilà ce qu'ils contrôlent. Nombreux, très rapides, peu coûteux à maintenir. Leur limite ? Ils ne prouvent pas que les pièces s'emboîtent bien entre elles. Une fonction de paiement parfaite peut très bien recevoir de mauvaises données d'une autre partie du programme.

Les tests d'intégration : les pièces ensemble

Ici, on vérifie que plusieurs modules communiquent correctement. Par exemple, que votre code enregistre bien une commande dans la base de données, ou qu'il dialogue sans erreur avec l'API d'un transporteur. Plus lents, ces tests sollicitent de vrais composants. Ils attrapent pourtant toute une famille d'erreurs invisibles pour les tests unitaires : problèmes de connexion, de format de données, de configuration.

Les tests end-to-end : le parcours complet

Souvent abrégé E2E, le test end-to-end simule un vrai utilisateur. Un robot ouvre un navigateur, va sur la page produit, ajoute un article au panier, remplit le formulaire, valide la commande. Toute la chaîne y passe, du front end au back end. Pour ce genre de tests, on s'appuie sur des outils comme Playwright, Cypress ou Selenium.

Sur les parcours qui rapportent de l'argent (inscription, devis, achat), ils sont précieux. Mais lents, plus fragiles, plus chers à entretenir. Il suffit parfois d'un libellé de bouton modifié pour les faire échouer ! Mon conseil : écrivez-en peu, et réservez-les aux scénarios critiques.

Tests fonctionnels et tests d’acceptation

Une fonctionnalité répond-elle aux exigences, du point de vue de l'utilisateur ? C'est la question des tests fonctionnels, qui ignorent le code interne. Les tests d’acceptation vont un cran plus loin : ils confirment que le logiciel correspond bien à ce que le client a commandé. On les rédige souvent avec lui, en langage courant, et ils servent de base à la recette avant la mise en production. En général, tout cela se déroule sur un environnement de préproduction, copie fidèle du site réel.

La pyramide des tests

Pour organiser ces niveaux, les équipes s'appuient sur une image classique : la pyramide des tests. Plus on monte, plus les tests sont lents et coûteux. Donc moins on en écrit.

• À la base, beaucoup de tests unitaires : rapides, ciblés, lancés à chaque modification.
• Au milieu, une dose raisonnable de tests d'intégration sur les échanges entre modules et services.
• Au sommet, quelques tests end-to-end, sur les parcours qui comptent vraiment pour le chiffre d'affaires.
• À côté, des tests d’acceptation validés avec le client avant chaque livraison importante.

Une stratégie cohérente vaut mieux qu'une accumulation de tests sans logique. Et méfiez-vous de la pyramide inversée, bourrée de tests E2E : elle produit des suites lentes, capricieuses, que l'équipe finit par ignorer.

Comment faire des tests unitaires : la mise en place

Quel que soit le langage de programmation, la logique ne change pas. Vous choisissez un framework de test adapté, vous écrivez les tests à côté du code, puis vous les lancez à chaque modification. Concrètement, ça donne ceci.

La structure d'un test : préparer, agir, vérifier

La plupart des cas de tests suivent un schéma en trois temps, baptisé Arrange, Act, Assert par les anglophones. Préparer d'abord les données d'entrée. Appeler ensuite la fonction à tester. Comparer enfin le résultat obtenu au résultat attendu. Un bon test ne vérifie qu'une chose et porte un nom qui dit ce qu'il contrôle, par exemple « test_livraison_offerte_au_dessus_du_seuil ».

Des tests unitaires en Python avec pytest

En Python, deux outils dominent : unittest, inclus d'office dans le langage, et pytest, apprécié pour sa syntaxe légère (c'est mon préféré). Prenons une fonction calculer_ttc(prix_ht) qui renvoie le prix majoré de 20 %. Deux lignes suffisent au test : def test_calcul_ttc(): puis assert calculer_ttc(100) == 120. Et pour vérifier qu'un prix négatif est refusé ? On écrit with pytest.raises(ValueError): calculer_ttc(-5).

Reste à taper pytest dans le terminal. L'outil repère tout seul les fichiers dont le nom commence par test_, lance l'exécution des tests et affiche un résumé : tests passés, tests en échec, ligne fautive. Difficile de trouver plus simple pour découvrir les tests unitaires, même en débutant.

Des tests unitaires en PHP avec PHPUnit

Côté PHP, langage omniprésent sur les sites web et les CMS, la référence s'appelle PHPUnit. On crée une classe de test qui hérite de TestCase, puis une méthode contenant une assertion, par exemple $this->assertSame(120.0, $calculateur->ttc(100)). Pour exécuter les tests du projet, une commande : vendor/bin/phpunit. Certains développeurs lui préfèrent Pest, construit au-dessus de PHPUnit, dont l'écriture est plus concise.

Et dans les autres langages

Chaque écosystème a ses outils ; le principe, lui, ne bouge pas. Java ? JUnit, l'un des tout premiers frameworks du genre. En C# et .NET, on choisit entre xUnit, NUnit et MSTest. Les applications Angular ont longtemps tourné avec Jasmine et Karma, tandis que les projets récents se tournent vers Jest ou Vitest. Ces deux-là sont également courants en JavaScript côté serveur. Même les applications mobiles ont leurs outils dédiés, comme XCTest sur iOS.

Automatiser les tests unitaires

Écrire les tests ne suffit pas, encore faut-il les lancer systématiquement. C'est le rôle de l'intégration continue, qu'on appelle souvent CI. À chaque envoi de code sur le dépôt Git, un service comme GitHub Actions ou GitLab CI exécute toute la suite de tests sur un serveur. Un seul test échoue ? La modification est bloquée et ne part pas en production.

Ce garde-fou change tout. Plus besoin de penser à lancer les tests à la main, ni même de savoir les faire tourner en local pour en profiter : le contrôle se fait tout seul, pour chaque développeur et chaque modification. La pratique s'intègre naturellement à une méthode agile, où l'on livre souvent, par petites étapes. Sur nos projets de création de logiciel, c'est précisément ce mécanisme qui nous permet de livrer vite sans sacrifier la fiabilité.

Les erreurs courantes avec les tests unitaires

Bien pensés, les tests apportent beaucoup. Mal pensés, ils perdent vite leur valeur, à cause de réflexes pourtant fréquents. Voici les pièges que je rencontre le plus souvent sur les tests d'un projet web.

• Viser 100 % de couverture à tout prix : la couverture mesure la part du code exécutée par les tests, pas la qualité des vérifications. Un test peut traverser une fonction sans rien contrôler d'utile.
• Tester le détail interne plutôt que le comportement : si la moindre réorganisation du code casse les tests, ils deviennent un frein au lieu d'une aide.
• Écrire des tests qui dépendent les uns des autres : chaque test doit pouvoir tourner seul, dans n'importe quel ordre.
• Oublier les cas limites (valeur nulle, champ vide, montant pile au seuil, date du 29 février). C'est là que les bugs se cachent.
• Laisser des tests en échec, ou les désactiver : l'équipe s'habitue au rouge et ne voit plus les vraies alertes.
• Ne tester qu'à la fin du projet : ajouter des tests sur un code déjà écrit prend plus de temps et rapporte moins que de les écrire au fil de l'eau.
• Confondre les niveaux : tout vérifier par des tests end-to-end donne une suite lente et fragile, alors que la plupart des règles se testent mieux à l'échelle unitaire.

Dernier point : les tests ne remplacent pas tout. Ergonomie, vitesse d'affichage, pertinence d'une fonctionnalité pour vos clients ? Ils n'en disent rien. Ils s'inscrivent dans une démarche qualité plus large, qui inclut la maintenance du site web et la surveillance en production. Vous lancez un MVP ? Commencez par tester uniquement les règles qui touchent à l'argent, puis étoffez la suite à mesure que le produit grandit.

Questions fréquentes