🕷️ Crawler Inspector

URL Lookup

Direct Parameter Lookup

Raw Queries and Responses

1. Shard Calculation

Query:

Response:

Calculated Shard: 152 (from laksa144)

2. Crawled Status Check

Query:

curl -X POST \
  'http://laksa152.int.ahrefs:8124/' \
  -H 'Content-Type: text/plain' \
  -H 'X-ClickHouse-Database: crawler3' \
  -H 'Authorization: Basic YXBpOg==' \
  -d 'SELECT getAhrefsURLFromUnparsed(src_unparsed) AS found_url, ifNull(toUnixTimestamp(download_stamp), 0) AS crawl_time, ifNull(toUnixTimestamp(props_url_first_seen), 0) AS first_indexed_time, download_http_code AS http_code, src_unparsed AS src_unparsed, src_root_hash AS src_root_hash, history_drop_reason AS history_drop_reason, meta_title AS meta_title, meta_descriptions AS meta_descriptions, attrs_boilerpipe_text AS attrs_boilerpipe_text, attrs_markdown AS attrs_markdown, attrs_readable_markdown AS attrs_readable_markdown, meta_canonical AS meta_canonical FROM crawler3.page_info_local FINAL PREWHERE (src_root_hash, src_unparsed) IN ((getAhrefsRootHashFromUnparsed(getAhrefsUnparsedNoserviceFromURL(\'https://fr.wikipedia.org/wiki/Test_unitaire\')), getAhrefsUnparsedNoserviceFromURL(\'https://fr.wikipedia.org/wiki/Test_unitaire\'))) FORMAT JSONEachRow'

Response:

{"found_url":"https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire","crawl_time":1771754541,"first_indexed_time":1376075725,"http_code":200,"src_unparsed":"org,wikipedia!fr,\/wiki\/Test_unitaire s443","src_root_hash":"17790707453426894952","history_drop_reason":null,"meta_title":"Test unitaire — Wikipédia","meta_descriptions":[],"attrs_boilerpipe_text":"Un article de Wikipédia, l'encyclopédie libre.\nEn\nprogrammation informatique\n, le\ntest unitaire\n(ou\nTU\n, voire\nUT\npour\nUnit Testing\nen anglais) est une procédure permettant de vérifier le bon fonctionnement d'une partie précise d'un\nlogiciel\nou d'une portion d'un\nprogramme\n(appelée « unité » ou « module »).\nDans les applications non critiques, l'écriture des tests unitaires a longtemps été considérée comme une tâche secondaire. Cependant, les méthodes\nextreme programming\n(XP) et\ntest driven development\n(TDD) ont remis les tests unitaires, appelés « tests du programmeur », au centre de l'activité de programmation.\nLes tests unitaires, en tant que principe de tester séparément des parties plus élémentaires d'un logiciel complexe, remonte aux débuts de l'\ningénierie logicielle\n. En Juin 1956, H.D. Benington présente en effet le projet\nSAGE\nau symposium sur les méthodes de programmation avancée organisé par la\nmarine américaine\n. L'approche utilisée prévoyait à l'issue de la phase de codage une étape de\n« tests de paramètres »\npour valider la conformité des sous-programmes et composants à leur spécifications, avant de procéder à un\n« test d'assemblage »\nde ces composants\n[\n1\n]\n,\n[\n2\n]\n.\nEn 1964, une approche similaire est décrite pour les logiciels du\nprogramme Mercury\n : les unités individuelles développées par différentes organisations étaient soumises à des  \"tests unitaires\" avant d'être intégrées entre elles. En 1969, les méthodologies de tests sont structurées encore davantage, avec des tests unitaires, des tests de composants, et des\ntests d'intégration\n, dans le but de valider des parties élémentaires du logiciel séparément, puis de vérifier le bon fonctionnement des assemblages progressif en blocs plus larges\n[\n3\n]\n.  Des normes publiques adoptées à la fin des années 60, telles que les standards militaires MIL-STD-483\n[\n4\n]\net MIL-STD-490 de l'armée américaine contribuent à une large reconnaissance et adoption des tests unitaires au sein de gros projets.\nLes tests unitaires étaient alors interactifs\n[\n2\n]\n, ou automatisés\n[\n5\n]\n, utilisant soit des tests programmés ou des outils de capture et répétition automatisés.  En 1994\nKent Beck\ndécrit un environnement cadre de test pour le langage\nSmalltalk\n, qui deviendra\nSUnit\n[\n6\n]\npar la suite\n[\n7\n]\n,\n[\n8\n]\n. En 1997,\nKent Beck\nrencontre\nErich Gamma\navec lequel il crée\nJUnit\nqui, par sa popularité, entraînera la création de nombreux\nframeworks\nde tests unitaires, cet ensemble se nomme\nxUnit\n[\n9\n]\n.\nÀ la même époque, ATTOL Unit test est développé, puis utilisé par\nSextant Avionique\nen 1998\n[\n10\n]\nOn écrit un test pour confronter une réalisation à sa\nspécification\n. Le\ntest\ndéfinit un critère d'arrêt (état ou sorties à l'issue de l'exécution) et permet de statuer sur le succès ou sur l'échec d'une vérification. Grâce à la spécification, on est en mesure de faire correspondre un état d'entrée donné à un résultat ou à une sortie. Le\ntest\npermet de vérifier que la relation d'entrée \/ sortie donnée par la spécification est bel et bien réalisée.\nLa méthode XP préconise d'écrire les tests en même temps, ou même avant la fonction à tester (\nTest Driven Development\n). Ceci permet de définir précisément l'interface du module à développer. Les tests sont exécutés durant tout le développement, permettant de visualiser si le code fraîchement écrit correspond au besoin.\nLors d'une modification d'un programme, les tests unitaires signalent les éventuelles\nrégressions\n. En effet, certains tests peuvent échouer à la suite d'une modification, il faut donc soit réécrire le test pour le faire correspondre aux nouvelles attentes, soit corriger l'erreur se situant dans le code.\nLes tests unitaires peuvent servir de complément à\nl'API\n, il est très utile de lire les tests pour comprendre comment s'utilise une méthode. De plus, il est possible que la documentation ne soit plus à jour, mais les tests eux correspondent à la réalité de l'application.\nOn définit généralement 4 phases dans l'exécution d'un test unitaire :\nInitialisation\n(fonction\nsetUp\n) : définition d'un environnement de test complètement reproductible (une\nfixture\n).\nExercice\n : le module à tester est exécuté.\nVérification\n(utilisation de fonctions\nassert\n) : comparaison des résultats obtenus avec un vecteur de résultat défini. Ces tests définissent le résultat du test : SUCCÈS (\nSUCCESS\n) ou ÉCHEC (\nFAILURE\n). On peut également définir d'autres résultats comme ÉVITÉ (\nSKIPPED\n).\nDésactivation\n(fonction\ntearDown\n) : désinstallation des\nfixtures\npour retrouver l'état initial du système, dans le but de ne pas polluer les tests suivants. Tous les tests doivent être indépendants et reproductibles unitairement (quand exécutés seuls).\nIl s'agit pour le programmeur de tester un\nmodule\n, indépendamment du reste du programme, ceci afin de s'assurer qu'il réponde aux\nspécifications fonctionnelles\net qu'il fonctionne correctement en toutes circonstances. Cette vérification est considérée comme essentielle, en particulier dans les applications critiques. Elle s'accompagne couramment d'une vérification de la\ncouverture de code\n(évaluation de la couverture structurelle), qui consiste à s'assurer que l'ensemble des\ntests\nconduit à exécuter l'ensemble (ou une fraction déterminée) des instructions présentes dans le code.\nL'ensemble des tests unitaires doit être rejoué après une modification du code afin de vérifier qu'il n'y a pas de\nrégressions\n(l'apparition de nouveaux dysfonctionnements). L'emploi d'une « stratégie de test » particulière\npeut\nlimiter les tests à rejouer, par exemple : une analyse d'impact des modifications, corrélée à une preuve d'indépendance des modules, permet de cibler les cas de test unitaire à rejouer.\nUn test doit correspondre aux spécifications de l'application, il faut donc écrire les tests en premier puis les faire passer par la suite plutôt que d'écrire le code avant et de prendre le risque d'être influencé par celui-ci lors de la rédaction des tests\n[\n11\n]\n. Bob Martin\n[\n12\n]\n, grand défenseur de la méthode\nTDD\n, propose un\nmodèle\nsimple pour l'écriture des tests unitaires :\nÉcrire une fonction de test qui doit obtenir un résultat défini dans les spécifications. Ce code appelant un code qui n'existe pas encore, celui-ci doit échouer. Ceci a pour but de définir une fonction qui teste « quelque chose ».\nÉcrire le code (le minimum de « quelque chose ») pour faire réussir le test.\nUne fois le test en succès, rajouter un autre test pour obtenir un résultat légèrement différent, en faisant varier les entrées par exemple. Ce nouveau test fera faillir le code principal.\nModifier le code principal pour faire réussir les tests.\nRecommencer, en éliminant et\nrefactorisant\nles éventuelles redondances dans le code des tests. On refactorise en même temps le code principal que le code des tests.\nUn test unitaire doit tester une caractéristique et une seule. On ne définit pas un « \nscénario\n » de test complexe dans un test unitaire.\nIl est déconseillé de tester les détails d'implémentation telles que les fonctions privées d'une classe, on se concentrera à tester les fonctions publiques, c'est-à-dire les interfaces avec lesquelles les acteurs extérieurs interagissent. Ainsi, on découple les tests de l'implémentation et on se concentre sur la vérification du comportement attendu tout en gardant une flexibilité sur la manière d'arriver au résultat souhaité.\nLes\nmocks\nsont des objets permettant de simuler un objet réel de façon contrôlée. Dans certains cas, l'utilisation de mock est primordiale, pour un gain de temps de\ncouverture de code\n, et de fiabilité des tests\n[\n13\n]\npour simuler une\nbase de données\n, un\nservice web\n, etc., les interactions entre l'application et ces outils prennent du temps, l'utilisation de mock pour simuler leurs fonctionnements peut être un gain de temps considérable ;\ncertains cas d'erreurs sont très difficile à reproduire, l'utilisation de mock permet ici de simuler une erreur pour pouvoir traiter ce cas et donc améliorer la couverture de code, par exemple le catch d'une exception ;\nsans l'utilisation de mock, le test peut retourner une erreur ne provenant pas du code qui est testé (par exemple une base de données).\nCependant, une utilisation abusive de mock peut avoir l'effet inverse, notamment allonger le temps d'exécution des tests, rendre les tests compliqués à comprendre et à maintenir.\nLa plupart des\nframeworks\nde la famille\nxUnit\npermettent la génération des classes de test unitaire. Cependant ces frameworks ne fournissent que le squelette des classes. Les tests devront donc être écrits par le développeur.\nLa génération de tests unitaires est un sujet important pour les chercheurs et plusieurs conférences s'intéressent à cette problématique, telles que\nInternational Symposium on Software Testing and Analysis\n(ISSTA),\nInternational Conference on Software Engineering\n(ICSE) et\nAutomated Software Engineering\n(ASE).\nLors d'une modification dans le code d'un programme, il se peut que certains tests ne passent plus ; dans ce cas, le développeur doit déterminer si cela vient du code en lui-même ou du test : si cela vient du test, le développeur doit modifier son test car la suppression de celui-ci entraînerait une augmentation des chances de régression du programme. Certains chercheurs ont développé des outils pour résoudre ce problème.\nReAssert\n[\n14\n]\nest un outil suggérant des réparations pour un test qui échoue, il analyse les tests à modifier et suggère des changements au développeur, si cette suggestion convient au développeur, il peut effectuer le changement en cliquant sur un bouton.\nLes tests unitaires paramétrables sont des tests unitaires qui prennent des paramètres. Ils peuvent ensuite utiliser des outils comme QuickCheck pour générer des paramètres. Ces tests sont supportés par\nJUnit\n,\nTestNG\net NUnit.\nEn s'appuyant sur des cas concrets d'entrée et sortie, la génération d'Oracle et sur la couverture de test pour minimiser les cas, des chercheurs ont réussi à générer des tests unitaires paramétrables\n[\n15\n]\n. Les résultats de cette méthode sont prometteurs.\nIl existe une multitude de cadriciels (\nframework\n) permettant de réaliser facilement des tests unitaires. Il en existe dans les principaux\nlangages de programmation\n. Par exemple\nTest::More\n[\n16\n]\npour le\nPerl\n.\nLe terme générique « \nxUnit\n » désigne un outil permettant de réaliser des tests unitaires dans un langage donné (dont l'initiale remplace « x » le plus souvent).\nAUnit\n[\n17\n]\npour\nAda\n ;\nASUnit\n[\n18\n]\npour\nActionScript\n ;\nCppunit\n[\n19\n]\npour\nC++\n ;\nCUnit\n[\n20\n]\npour\nC\n ;\nDUnit pour\nDelphi\n ;\nFLEXunit pour\nAdobe Flex\n ;\nGoogle\nTest\n[\n21\n]\net Boost Test\n[\n22\n]\npour\nC++\n ;\nHUnit\n[\n23\n]\npour\nHaskell\n ;\nJSUnit\n[\n24\n]\n, QUnit\n[\n25\n]\n,\nUnit.js\n[\n26\n]\net Jest\n[\n27\n]\npour\nJavaScript\n ;\nJUnit\n[\n28\n]\net\nTestNG\n[\n29\n]\npour\nJava\n ;\nNUnit\n[\n30\n]\npour\n.NET\n ;\nMicrosoft\nUnit Test\n[\n31\n]\npour\n.NET\n ;\nxUnit\n[\n32\n]\npour\n.NET\n ;\nNUnitASP\n[\n33\n]\npour\nASP.NET\n(support interrompu depuis le\n31 janvier 2008\n) ;\nOUnit\n[\n34\n]\npour\nOCaml\n ;\nOCunit pour\nObjective C\n ;\nPBUnit pour\nPowerBuilder\n ;\nPHPUnit\n[\n35\n]\n, SimpleTest\n[\n36\n]\net Atoum\n[\n37\n]\npour\nPHP\n ;\nplunit pour\nProlog\n ;\nutPLSQL\n[\n38\n]\npour\nPL\/SQL\n ;\nUnittest et\nPyUnit\npour\nPython\n ;\nTape\npour\nJavaScript\n ;\nTest::Unit pour\nRuby\n ;\nTest::More pour\nPerl\n ;\nTypemock\npour .NET, C++, C#. Avec Typemock vous pouvez travailler sur legacy code aussi.\nSUnit\n[\n39\n]\npour\nSmalltalk\n ;\nRPGUnit\n[\n40\n]\npour RPG ;\nScalaTest pour Scala\nSASUnit\n[\n41\n]\npour\nSAS\n.\nDivers outils permettent l'automatisation des tests unitaires :\nLe module TBrun de la suite d'outils\nLDRA\n ;\nTessy (distribution :\nHitex Development Tools\n\/Allemagne).\nPonicode, génération de tests unitaires en Javascript\n[\n42\n]\n.\nCycle en V\nTest\nExtreme programming\nTest Driven Development\n↑\n(en)\nBenington, Herbert D., « \nProduction of large computer programs\n »,\nProceedings of the Symposium on Advanced Programming Methods for Digital Computers, Washington, D.C., June 28-29, 1956\n, Office of Naval Research, Department of the Navy,‎\n1956\n,\np.\n \n15-28\n↑\na\net\nb\nH. D.\nBenington\n, « \nProduction of large computer programs\n »,\nProceedings of the 9th international conference on Software Engineering\n, IEEE Computer Society Press, iCSE '87,‎\n1\ner\nmars 1987\n,\np.\n \n299–310\n(\nISBN\n \n978-0-89791-216-7\n,\nDOI\n \n10.5555\/41765.41799\n,\nlire en ligne\n, consulté le\n3 avril 2024\n)\n↑\nNorman A.\nZimmerman\n, « \nSystem integration as a programming function\n »,\nProceedings of the 1969 24th national conference\n, Association for Computing Machinery, aCM '69,‎\n26 août 1969\n,\np.\n \n459–467\n(\nISBN\n \n978-1-4503-7493-4\n,\nDOI\n \n10.1145\/800195.805951\n,\nlire en ligne\n, consulté le\n3 avril 2024\n)\n↑\n(en)\nGouvernement des Etats Unis d'Amérique,  Département de la Défence,\nMIL-STD-483 Military standard: configuration management practices for systems, equipment, munitions, and computer programs\n,\n31 décembre 1970\n, Section 3.4.7.2. \"The contractor shall then code and test software Units, and enter the source and object code, and associated listings of each successfully tested Unit into the Developmental Configuration\"\n↑\n(en)\nMichael F.\nTighe\n, « \nThe value of a proper software quality assurance methodology\n »,\nACM SIGMETRICS Performance Evaluation Review\n,\nvol.\n 7,\nn\nos\n 3-4,‎\nnovembre 1978\n,\np.\n \n165–172\n(\nISSN\n \n0163-5999\n,\nDOI\n \n10.1145\/1007775.811118\n,\nlire en ligne\n, consulté le\n3 avril 2024\n)\n↑\nCamp Smalltalk SUnit\n↑\nSimple Smalltalk Testing:With Patterns\n, in\nSmalltalk Report\noctobre 1994, Kent Beck\n↑\n(en)\nWard Cunningham, « \nTesting Framework\n »\n, sur\nwiki.c2.com\n.\n↑\nXunit, Martin Fowler\n↑\nGNU Based Compilation System for Space Embedded Applications, Blondin, J. P. & Martignano, M., DASIA 98 - Data Systems in Aerospace, Proceedings of the conference held 25-28 May, 1998 in Athens, Greece, Edited by B. Kaldeich-Schü.rmann. ESA SP-422. Paris: European Space Agency, 1998., p.137, \"1998ESASP.422..137B\", page 138\nhttp:\/\/adsbit.harvard.edu\/\/full\/1998ESASP.422..137B\/0000138.000.html\n↑\nUnit Testing Best Practices, Roy Osherove\n.\n↑\nTest First, bob Martin\n.\n↑\nRobert Martin,\nWhen to Mock\n.\n↑\n(en)\nBrett Daniel, Danny Dig, Tihomir Gvero, Vilas Jagannath, Johnston Jiaa, Damion Mitchell, Jurand Nogiec, Shin Hwei Tan et Darko Marinov, « \nReAssert: a tool for repairing broken unit tests\n »,\nICSE\n,‎\n2011\n(\nlire en ligne\n)\n.\n↑\n(en)\nGordon Fraser et Andreas Zeller, « \nGenerating Parameterized Unit Tests\n »,\nISSTA\n,‎\n2011\n(\nlire en ligne\n)\n.\n↑\nTest::More sur CPAN\n, entre autres\nmodules de tests\n. Voir aussi les articles de l'association des\nmongueurs de Perl\ndans\nLinux Magazine France\ndisponibles sur\nhttp:\/\/articles.mongueurs.net\/magazines\n↑\nAUnit\n↑\nAsUnit\n↑\nCppUnit\net en\nversion 2\n↑\nCUnit\n↑\nGoogleTest\n↑\nBoost.Test\n↑\nHUnit\n↑\nJsUnit\n↑\nhttp:\/\/qunitjs.com\nUnit testing for Javascript made by the jQuery Foundation\n↑\n(en)\nUnit JS\n : « \nUnit testing framework for Javascript\n ».\n↑\n(en)\n« \nJest · 🃏 Delightful JavaScript Testing\n », sur\njestjs.io\n(consulté le\n2 mars 2020\n)\n.\n↑\nWelcome to The New JUnit.org! | JUnit.org\n.\n↑\n(en)\n« \nTestNG Documentation\n », sur\ntestng.org\n(consulté le\n21 mai 2024\n)\n.\n↑\nNUnit - Home\n↑\n(en-US)\nerickson-doug\n, « \nWriting Unit Tests for the .NET Framework with the Microsoft Unit Test Framework for Managed Code - Visual Studio\n », sur\ndocs.microsoft.com\n(consulté le\n4 septembre 2018\n)\n.\n↑\n(en)\n« \nHome > xUnit.net\n », sur\nxunit.github.io\n(consulté le\n4 septembre 2018\n)\n.\n↑\nNUnitAsp - ASP.NET unit testing\n↑\nOUnit\n↑\nPHPUnit - Trac\n↑\nSimpleTest - Unit Testing for PHP\n↑\nAtoum\n↑\nutPLSQL\n↑\nSimple Smalltalk Testing: With Patterns\n↑\nhttp:\/\/rpgunit.sourceforge.net\/\n↑\n(en)\n« \nSASUnit\n », sur\nSourceForge\n(consulté le\n24 février 2020\n)\n.\n↑\n(en)\n« \nPonicode - Quick and easy Javascript unit testing\n », sur\nponicode.com\n(consulté le\n23 juin 2020\n)\n.\nv\n ·\nm\nGestion de la\nqualité logicielle\nIndicateurs de qualité\n(\nISO\/CEI 9126\n)\nCapacité fonctionnelle (réponse aux\nexigences\n)\nFiabilité\nMaintenabilité\nPerformance\nPortabilité\nUtilisabilité\nCompréhension et contrôle du\ncode source\nAutomatisation de test\nCommentaires\nDocumentation\nInspection de produit\nProgrammation en binôme\nou\nen groupe\nRègles de codage\nRevue de code\nTests\nAcceptation\nIntégration\nPerformance\nRégression\nUnitaire\nUtilisateur\nValidation\nMétriques\nCohésion\nCouplage\nCouverture de code\nHalstead\nIndépendance fonctionnelle\nIndice de maintenabilité\nLigne de code\nNombre cyclomatique\nPoint de fonction\nRemaniements\nMaintenance\nOptimisation de code\nRéusinage de code\n(\nRègle de trois\n)\nPrincipes de\nprogrammation\nEncapsulation\nGRASP\nKISS\nLoi de Déméter\nMasquage de l'information\nNe vous répétez pas (DRY)\nPatron de conception\nSéparation des préoccupations\nYAGNI\nSOLID\nResponsabilité unique\nOuvert\/fermé\nSubstitution de Liskov\nSégrégation des interfaces\nInversion des dépendances\nMauvaises pratiques\nAntipatterns\nAttente active\nGrosse boule de boue\nProgrammation spaghetti\n(\nsyndrome\n)\nRéinventer la roue\nCode smells\nDuplication de code\nGod object\nVoir aussi :\nGénie logiciel\n,\nSoftware craftsmanship\n,\nDégradation logicielle\nPortail de l’informatique","attrs_markdown":"[Aller au contenu](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#bodyContent)\n\nMenu principal\n\nMenu principal\n\ndéplacer vers la barre latérale\n\nmasquer\n\nNavigation\n\n- [Page d’accueil](https:\/\/fr.wikipedia.org\/wiki\/Wikip%C3%A9dia:Accueil_principal \"Accueil général [z]\")\n- [Portails thématiques](https:\/\/fr.wikipedia.org\/wiki\/Portail:Accueil \"Regroupements d'articles par thématiques\")\n- [Article au hasard](https:\/\/fr.wikipedia.org\/wiki\/Sp%C3%A9cial:Page_au_hasard \"Affiche un article au hasard [x]\")\n- [Contact](https:\/\/fr.wikipedia.org\/wiki\/Wikip%C3%A9dia:Contact \"Qui contacter\")\n\nContribuer\n\n- [Débuter sur Wikipédia](https:\/\/fr.wikipedia.org\/wiki\/Aide:D%C3%A9buter \"Guide pour apprendre à contribuer à Wikipédia\")\n- [Aide](https:\/\/fr.wikipedia.org\/wiki\/Aide:Accueil \"Accès à l’aide\")\n- [Communauté](https:\/\/fr.wikipedia.org\/wiki\/Wikip%C3%A9dia:Accueil_de_la_communaut%C3%A9 \"À propos du projet, ce que vous pouvez faire, où trouver les informations\")\n- [Pages spéciales](https:\/\/fr.wikipedia.org\/wiki\/Sp%C3%A9cial:Pages_sp%C3%A9ciales \"Outils pour contribuer à Wikipédia [q]\")\n- [Modifications récentes](https:\/\/fr.wikipedia.org\/wiki\/Sp%C3%A9cial:Modifications_r%C3%A9centes \"Liste des modifications récentes sur le wiki [r]\")\n\n[![](https:\/\/fr.wikipedia.org\/static\/images\/icons\/wikipedia.png) ![Wikipédia](https:\/\/fr.wikipedia.org\/static\/images\/mobile\/copyright\/wikipedia-wordmark-fr.svg) ![l'encyclopédie libre](https:\/\/fr.wikipedia.org\/static\/images\/mobile\/copyright\/wikipedia-tagline-fr.svg)](https:\/\/fr.wikipedia.org\/wiki\/Wikip%C3%A9dia:Accueil_principal)\n\n[Rechercher](https:\/\/fr.wikipedia.org\/wiki\/Sp%C3%A9cial:Recherche \"Rechercher sur Wikipédia [f]\")\n\nApparence\n\n- [Faire un don](https:\/\/donate.wikimedia.org\/?wmf_source=donate&wmf_medium=sidebar&wmf_campaign=fr.wikipedia.org&uselang=fr)\n- [Créer un compte](https:\/\/fr.wikipedia.org\/w\/index.php?title=Sp%C3%A9cial:Cr%C3%A9er_un_compte&returnto=Test+unitaire \"Nous vous encourageons à créer un compte utilisateur et vous connecter ; ce n’est cependant pas obligatoire.\")\n- [Se connecter](https:\/\/fr.wikipedia.org\/w\/index.php?title=Sp%C3%A9cial:Connexion&returnto=Test+unitaire \"Nous vous encourageons à vous connecter ; ce n’est cependant pas obligatoire. [o]\")\n\nOutils personnels\n\n- [Faire un don](https:\/\/donate.wikimedia.org\/?wmf_source=donate&wmf_medium=sidebar&wmf_campaign=fr.wikipedia.org&uselang=fr)\n- [Créer un compte](https:\/\/fr.wikipedia.org\/w\/index.php?title=Sp%C3%A9cial:Cr%C3%A9er_un_compte&returnto=Test+unitaire \"Nous vous encourageons à créer un compte utilisateur et vous connecter ; ce n’est cependant pas obligatoire.\")\n- [Se connecter](https:\/\/fr.wikipedia.org\/w\/index.php?title=Sp%C3%A9cial:Connexion&returnto=Test+unitaire \"Nous vous encourageons à vous connecter ; ce n’est cependant pas obligatoire. [o]\")\n\n## Sommaire\ndéplacer vers la barre latérale\n\nmasquer\n\n- [Début](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire)\n- [1 Origine et histoire](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#Origine_et_histoire)\n- [2 Utilité](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#Utilit%C3%A9)\n  Afficher \/ masquer la sous-section Utilité\n  - [2\\.1 Trouver les erreurs rapidement](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#Trouver_les_erreurs_rapidement)\n  - [2\\.2 Sécuriser la maintenance](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#S%C3%A9curiser_la_maintenance)\n  - [2\\.3 Documenter le code](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#Documenter_le_code)\n- [3 Fonctionnement](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#Fonctionnement)\n- [4 Utilisation](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#Utilisation)\n  Afficher \/ masquer la sous-section Utilisation\n  - [4\\.1 Commencer par les tests](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#Commencer_par_les_tests)\n  - [4\\.2 Utiliser des mocks](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#Utiliser_des_mocks)\n- [5 Génération](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#G%C3%A9n%C3%A9ration)\n  Afficher \/ masquer la sous-section Génération\n  - [5\\.1 Correction de test unitaire](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#Correction_de_test_unitaire)\n  - [5\\.2 Test unitaire paramétrable](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#Test_unitaire_param%C3%A9trable)\n- [6 Environnements de développement](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#Environnements_de_d%C3%A9veloppement)\n  Afficher \/ masquer la sous-section Environnements de développement\n  - [6\\.1 Frameworks xUnit](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#Frameworks_xUnit)\n- [7 Outils commerciaux](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#Outils_commerciaux)\n- [8 Articles connexes](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#Articles_connexes)\n- [9 Notes](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#Notes)\n\nBasculer la table des matières\n\n# Test unitaire\n29 langues\n\n- [العربية](https:\/\/ar.wikipedia.org\/wiki\/%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1_%D8%A7%D9%84%D9%88%D8%AD%D8%AF%D8%A9 \"اختبار الوحدة – arabe\")\n- [Български](https:\/\/bg.wikipedia.org\/wiki\/%D0%9A%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%BD%D0%BE_%D1%82%D0%B5%D1%81%D1%82%D0%B2%D0%B0%D0%BD%D0%B5 \"Компонентно тестване – bulgare\")\n- [Català](https:\/\/ca.wikipedia.org\/wiki\/Proves_unit%C3%A0ries \"Proves unitàries – catalan\")\n- [Čeština](https:\/\/cs.wikipedia.org\/wiki\/Unit_testing \"Unit testing – tchèque\")\n- [Dansk](https:\/\/da.wikipedia.org\/wiki\/Unit_test \"Unit test – danois\")\n- [Deutsch](https:\/\/de.wikipedia.org\/wiki\/Modultest \"Modultest – allemand\")\n- [English](https:\/\/en.wikipedia.org\/wiki\/Unit_testing \"Unit testing – anglais\")\n- [Español](https:\/\/es.wikipedia.org\/wiki\/Prueba_unitaria \"Prueba unitaria – espagnol\")\n- [Eesti](https:\/\/et.wikipedia.org\/wiki\/%C3%9Chiktestimine \"Ühiktestimine – estonien\")\n- [فارسی](https:\/\/fa.wikipedia.org\/wiki\/%D8%A2%D8%B2%D9%85%D9%88%D9%86_%D9%88%D8%A7%D8%AD%D8%AF \"آزمون واحد – persan\")\n- [Suomi](https:\/\/fi.wikipedia.org\/wiki\/Yksikk%C3%B6testaaminen \"Yksikkötestaaminen – finnois\")\n- [עברית](https:\/\/he.wikipedia.org\/wiki\/%D7%91%D7%93%D7%99%D7%A7%D7%95%D7%AA_%D7%99%D7%97%D7%99%D7%93%D7%94 \"בדיקות יחידה – hébreu\")\n- [Magyar](https:\/\/hu.wikipedia.org\/wiki\/Egys%C3%A9gtesztel%C3%A9s \"Egységtesztelés – hongrois\")\n- [Interlingua](https:\/\/ia.wikipedia.org\/wiki\/Proba_unitari \"Proba unitari – interlingua\")\n- [Bahasa Indonesia](https:\/\/id.wikipedia.org\/wiki\/Pengujian_unit \"Pengujian unit – indonésien\")\n- [Italiano](https:\/\/it.wikipedia.org\/wiki\/Unit_testing \"Unit testing – italien\")\n- [日本語](https:\/\/ja.wikipedia.org\/wiki\/%E5%8D%98%E4%BD%93%E3%83%86%E3%82%B9%E3%83%88 \"単体テスト – japonais\")\n- [한국어](https:\/\/ko.wikipedia.org\/wiki\/%EC%9C%A0%EB%8B%9B_%ED%85%8C%EC%8A%A4%ED%8A%B8 \"유닛 테스트 – coréen\")\n- [Nederlands](https:\/\/nl.wikipedia.org\/wiki\/Unittesten \"Unittesten – néerlandais\")\n- [Norsk bokmål](https:\/\/no.wikipedia.org\/wiki\/Enhetstesting \"Enhetstesting – norvégien bokmål\")\n- [Polski](https:\/\/pl.wikipedia.org\/wiki\/Test_jednostkowy \"Test jednostkowy – polonais\")\n- [Português](https:\/\/pt.wikipedia.org\/wiki\/Teste_de_unidade \"Teste de unidade – portugais\")\n- [Русский](https:\/\/ru.wikipedia.org\/wiki\/%D0%9C%D0%BE%D0%B4%D1%83%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5 \"Модульное тестирование – russe\")\n- [Српски \/ srpski](https:\/\/sr.wikipedia.org\/wiki\/%D0%9C%D0%BE%D0%B4%D1%83%D0%BB%D0%B0%D1%80%D0%BD%D0%BE_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%B0%D1%9A%D0%B5 \"Модуларно тестирање – serbe\")\n- [தமிழ்](https:\/\/ta.wikipedia.org\/wiki\/%E0%AE%93%E0%AE%B0%E0%AE%B2%E0%AE%95%E0%AF%81%E0%AE%9A%E0%AF%8D_%E0%AE%9A%E0%AF%8B%E0%AE%A4%E0%AE%A9%E0%AF%88 \"ஓரலகுச் சோதனை – tamoul\")\n- [Türkçe](https:\/\/tr.wikipedia.org\/wiki\/Birim_testi \"Birim testi – turc\")\n- [Українська](https:\/\/uk.wikipedia.org\/wiki\/%D0%9C%D0%BE%D0%B4%D1%83%D0%BB%D1%8C%D0%BD%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F \"Модульне тестування – ukrainien\")\n- [Tiếng Việt](https:\/\/vi.wikipedia.org\/wiki\/Unit_testing \"Unit testing – vietnamien\")\n- [中文](https:\/\/zh.wikipedia.org\/wiki\/%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95 \"单元测试 – chinois\")\n\n[Modifier les liens](https:\/\/www.wikidata.org\/wiki\/Special:EntityPage\/Q907375#sitelinks-wikipedia \"Modifier les liens interlangues\")\n\n- [Article](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire \"Voir le contenu de la page [c]\")\n- [Discussion](https:\/\/fr.wikipedia.org\/wiki\/Discussion:Test_unitaire \"Discussion au sujet de cette page de contenu [t]\")\n\nfrançais\n\n- [Lire](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire)\n- [Modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit \"Modifier cette page [v]\")\n- [Modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit \"Modifier le wikicode de cette page [e]\")\n- [Voir l’historique](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=history \"Historique des versions de cette page [h]\")\n\nOutils\n\nOutils\n\ndéplacer vers la barre latérale\n\nmasquer\n\nActions\n\n- [Lire](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire)\n- [Modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit \"Modifier cette page [v]\")\n- [Modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit \"Modifier le wikicode de cette page [e]\")\n- [Voir l’historique](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=history)\n\nGénéral\n\n- [Pages liées](https:\/\/fr.wikipedia.org\/wiki\/Sp%C3%A9cial:Pages_li%C3%A9es\/Test_unitaire \"Liste des pages liées qui pointent sur celle-ci [j]\")\n- [Suivi des pages liées](https:\/\/fr.wikipedia.org\/wiki\/Sp%C3%A9cial:Suivi_des_liens\/Test_unitaire \"Liste des modifications récentes des pages appelées par celle-ci [k]\")\n- [Téléverser un fichier](https:\/\/fr.wikipedia.org\/wiki\/Aide:Importer_un_fichier \"Téléverser des fichiers [u]\")\n- [Lien permanent](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&oldid=233485497 \"Adresse permanente de cette version de cette page\")\n- [Informations sur la page](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=info \"Davantage d’informations sur cette page\")\n- [Citer cette page](https:\/\/fr.wikipedia.org\/w\/index.php?title=Sp%C3%A9cial:Citer&page=Test_unitaire&id=233485497&wpFormIdentifier=titleform \"Informations sur la manière de citer cette page\")\n- [Obtenir l'URL raccourcie](https:\/\/fr.wikipedia.org\/w\/index.php?title=Sp%C3%A9cial:UrlShortener&url=https%3A%2F%2Ffr.wikipedia.org%2Fwiki%2FTest_unitaire)\n- [Télécharger le code QR](https:\/\/fr.wikipedia.org\/w\/index.php?title=Sp%C3%A9cial:QrCode&url=https%3A%2F%2Ffr.wikipedia.org%2Fwiki%2FTest_unitaire)\n\nImprimer \/ exporter\n\n- [Créer un livre](https:\/\/fr.wikipedia.org\/w\/index.php?title=Sp%C3%A9cial:Livre&bookcmd=book_creator&referer=Test+unitaire)\n- [Télécharger comme PDF](https:\/\/fr.wikipedia.org\/w\/index.php?title=Sp%C3%A9cial:DownloadAsPdf&page=Test_unitaire&action=show-download-screen)\n- [Version imprimable](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&printable=yes \"Version imprimable de cette page [p]\")\n\nDans d’autres projets\n\n- [Wikilivres](https:\/\/fr.wikibooks.org\/wiki\/Introduction_au_test_logiciel\/Tests_unitaires)\n- [Élément Wikidata](https:\/\/www.wikidata.org\/wiki\/Special:EntityPage\/Q907375 \"Lien vers l’élément dans le dépôt de données connecté [g]\")\n\nApparence\n\ndéplacer vers la barre latérale\n\nmasquer\n\nUn article de Wikipédia, l'encyclopédie libre.\n\n[![Page d’aide sur l’homonymie](https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/a\/a9\/Logo_disambig.svg\/20px-Logo_disambig.svg.png)](https:\/\/fr.wikipedia.org\/wiki\/Aide:Homonymie \"Aide:Homonymie\")\n\nPour les articles homonymes, voir [Test](https:\/\/fr.wikipedia.org\/wiki\/Test \"Test\").\n\nEn [programmation informatique](https:\/\/fr.wikipedia.org\/wiki\/Programmation_informatique \"Programmation informatique\"), le **test unitaire** (ou **TU**, voire ***UT*** pour *Unit Testing* en anglais) est une procédure permettant de vérifier le bon fonctionnement d'une partie précise d'un [logiciel](https:\/\/fr.wikipedia.org\/wiki\/Logiciel \"Logiciel\") ou d'une portion d'un [programme](https:\/\/fr.wikipedia.org\/wiki\/Programme_informatique \"Programme informatique\") (appelée « unité » ou « module »).\n\nDans les applications non critiques, l'écriture des tests unitaires a longtemps été considérée comme une tâche secondaire. Cependant, les méthodes [extreme programming](https:\/\/fr.wikipedia.org\/wiki\/Extreme_programming \"Extreme programming\") (XP) et [test driven development](https:\/\/fr.wikipedia.org\/wiki\/Test_driven_development \"Test driven development\") (TDD) ont remis les tests unitaires, appelés « tests du programmeur », au centre de l'activité de programmation.\n\n## Origine et histoire\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=1 \"Modifier la section : Origine et histoire\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=1 \"Modifier le code source de la section : Origine et histoire\")\\]\n\nLes tests unitaires, en tant que principe de tester séparément des parties plus élémentaires d'un logiciel complexe, remonte aux débuts de l'[ingénierie logicielle](https:\/\/fr.wikipedia.org\/wiki\/Ing%C3%A9nierie_logicielle \"Ingénierie logicielle\"). En Juin 1956, H.D. Benington présente en effet le projet [SAGE](https:\/\/fr.wikipedia.org\/wiki\/Semi-Automatic_Ground_Environment \"Semi-Automatic Ground Environment\") au symposium sur les méthodes de programmation avancée organisé par la [marine américaine](https:\/\/fr.wikipedia.org\/wiki\/United_States_Navy \"United States Navy\"). L'approche utilisée prévoyait à l'issue de la phase de codage une étape de « tests de paramètres » pour valider la conformité des sous-programmes et composants à leur spécifications, avant de procéder à un « test d'assemblage » de ces composants[\\[1\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-1),[\\[2\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-:0-2).\n\nEn 1964, une approche similaire est décrite pour les logiciels du [programme Mercury](https:\/\/fr.wikipedia.org\/wiki\/Programme_Mercury \"Programme Mercury\") : les unités individuelles développées par différentes organisations étaient soumises à des \"tests unitaires\" avant d'être intégrées entre elles. En 1969, les méthodologies de tests sont structurées encore davantage, avec des tests unitaires, des tests de composants, et des [tests d'intégration](https:\/\/fr.wikipedia.org\/wiki\/Test_d%27int%C3%A9gration \"Test d'intégration\"), dans le but de valider des parties élémentaires du logiciel séparément, puis de vérifier le bon fonctionnement des assemblages progressif en blocs plus larges[\\[3\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-3). Des normes publiques adoptées à la fin des années 60, telles que les standards militaires MIL-STD-483[\\[4\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-4) et MIL-STD-490 de l'armée américaine contribuent à une large reconnaissance et adoption des tests unitaires au sein de gros projets.\n\nLes tests unitaires étaient alors interactifs[\\[2\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-:0-2), ou automatisés[\\[5\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-5), utilisant soit des tests programmés ou des outils de capture et répétition automatisés. En 1994 [Kent Beck](https:\/\/fr.wikipedia.org\/wiki\/Kent_Beck \"Kent Beck\") décrit un environnement cadre de test pour le langage [Smalltalk](https:\/\/fr.wikipedia.org\/wiki\/Smalltalk \"Smalltalk\"), qui deviendra [SUnit](https:\/\/fr.wikipedia.org\/w\/index.php?title=SUnit&action=edit&redlink=1 \"SUnit (page inexistante)\")[\\[6\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-6) par la suite[\\[7\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-7),[\\[8\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-8). En 1997, [Kent Beck](https:\/\/fr.wikipedia.org\/wiki\/Kent_Beck \"Kent Beck\") rencontre [Erich Gamma](https:\/\/fr.wikipedia.org\/wiki\/Erich_Gamma \"Erich Gamma\") avec lequel il crée [JUnit](https:\/\/fr.wikipedia.org\/wiki\/JUnit \"JUnit\") qui, par sa popularité, entraînera la création de nombreux [frameworks](https:\/\/fr.wikipedia.org\/wiki\/Frameworks \"Frameworks\") de tests unitaires, cet ensemble se nomme [xUnit](https:\/\/fr.wikipedia.org\/wiki\/XUnit \"XUnit\")[\\[9\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-9).\n\nÀ la même époque, ATTOL Unit test est développé, puis utilisé par [Sextant Avionique](https:\/\/fr.wikipedia.org\/wiki\/Sextant_Avionique \"Sextant Avionique\") en 1998[\\[10\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-10)\n\n## Utilité\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=2 \"Modifier la section : Utilité\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=2 \"Modifier le code source de la section : Utilité\")\\]\n\nOn écrit un test pour confronter une réalisation à sa [spécification](https:\/\/fr.wikipedia.org\/wiki\/Sp%C3%A9cification_fonctionnelle \"Spécification fonctionnelle\"). Le [test](https:\/\/fr.wikipedia.org\/wiki\/Test_\\(informatique\\) \"Test (informatique)\") définit un critère d'arrêt (état ou sorties à l'issue de l'exécution) et permet de statuer sur le succès ou sur l'échec d'une vérification. Grâce à la spécification, on est en mesure de faire correspondre un état d'entrée donné à un résultat ou à une sortie. Le [test](https:\/\/fr.wikipedia.org\/wiki\/Test_\\(informatique\\) \"Test (informatique)\") permet de vérifier que la relation d'entrée \/ sortie donnée par la spécification est bel et bien réalisée.\n\n### Trouver les erreurs rapidement\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=3 \"Modifier la section : Trouver les erreurs rapidement\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=3 \"Modifier le code source de la section : Trouver les erreurs rapidement\")\\]\n\nLa méthode XP préconise d'écrire les tests en même temps, ou même avant la fonction à tester ([Test Driven Development](https:\/\/fr.wikipedia.org\/wiki\/Test_Driven_Development \"Test Driven Development\")). Ceci permet de définir précisément l'interface du module à développer. Les tests sont exécutés durant tout le développement, permettant de visualiser si le code fraîchement écrit correspond au besoin.\n\n### Sécuriser la maintenance\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=4 \"Modifier la section : Sécuriser la maintenance\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=4 \"Modifier le code source de la section : Sécuriser la maintenance\")\\]\n\nLors d'une modification d'un programme, les tests unitaires signalent les éventuelles [régressions](https:\/\/fr.wikipedia.org\/wiki\/Test_de_r%C3%A9gression \"Test de régression\"). En effet, certains tests peuvent échouer à la suite d'une modification, il faut donc soit réécrire le test pour le faire correspondre aux nouvelles attentes, soit corriger l'erreur se situant dans le code.\n\n### Documenter le code\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=5 \"Modifier la section : Documenter le code\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=5 \"Modifier le code source de la section : Documenter le code\")\\]\n\nLes tests unitaires peuvent servir de complément à [l'API](https:\/\/fr.wikipedia.org\/wiki\/Interface_de_programmation \"Interface de programmation\"), il est très utile de lire les tests pour comprendre comment s'utilise une méthode. De plus, il est possible que la documentation ne soit plus à jour, mais les tests eux correspondent à la réalité de l'application.\n\n## Fonctionnement\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=6 \"Modifier la section : Fonctionnement\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=6 \"Modifier le code source de la section : Fonctionnement\")\\]\n\nOn définit généralement 4 phases dans l'exécution d'un test unitaire :\n\n1. **Initialisation** (fonction `setUp`) : définition d'un environnement de test complètement reproductible (une [fixture](https:\/\/fr.wikipedia.org\/wiki\/Test_fixture \"Test fixture\")).\n2. **Exercice** : le module à tester est exécuté.\n3. **Vérification** (utilisation de fonctions `assert`) : comparaison des résultats obtenus avec un vecteur de résultat défini. Ces tests définissent le résultat du test : SUCCÈS (`SUCCESS`) ou ÉCHEC (`FAILURE`). On peut également définir d'autres résultats comme ÉVITÉ (`SKIPPED`).\n4. **Désactivation** (fonction `tearDown`) : désinstallation des [fixtures](https:\/\/fr.wikipedia.org\/wiki\/Test_fixture \"Test fixture\") pour retrouver l'état initial du système, dans le but de ne pas polluer les tests suivants. Tous les tests doivent être indépendants et reproductibles unitairement (quand exécutés seuls).\n\n## Utilisation\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=7 \"Modifier la section : Utilisation\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=7 \"Modifier le code source de la section : Utilisation\")\\]\n\nIl s'agit pour le programmeur de tester un [module](https:\/\/fr.wikipedia.org\/wiki\/Module_\\(programmation\\) \"Module (programmation)\"), indépendamment du reste du programme, ceci afin de s'assurer qu'il réponde aux [spécifications fonctionnelles](https:\/\/fr.wikipedia.org\/wiki\/Sp%C3%A9cification_\\(informatique\\) \"Spécification (informatique)\") et qu'il fonctionne correctement en toutes circonstances. Cette vérification est considérée comme essentielle, en particulier dans les applications critiques. Elle s'accompagne couramment d'une vérification de la [couverture de code](https:\/\/fr.wikipedia.org\/wiki\/Couverture_de_code \"Couverture de code\") (évaluation de la couverture structurelle), qui consiste à s'assurer que l'ensemble des [tests](https:\/\/fr.wikipedia.org\/wiki\/Test_\\(informatique\\) \"Test (informatique)\") conduit à exécuter l'ensemble (ou une fraction déterminée) des instructions présentes dans le code.\n\nL'ensemble des tests unitaires doit être rejoué après une modification du code afin de vérifier qu'il n'y a pas de [régressions](https:\/\/fr.wikipedia.org\/wiki\/Non-r%C3%A9gression \"Non-régression\") (l'apparition de nouveaux dysfonctionnements). L'emploi d'une « stratégie de test » particulière *peut* limiter les tests à rejouer, par exemple : une analyse d'impact des modifications, corrélée à une preuve d'indépendance des modules, permet de cibler les cas de test unitaire à rejouer.\n\n### Commencer par les tests\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=8 \"Modifier la section : Commencer par les tests\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=8 \"Modifier le code source de la section : Commencer par les tests\")\\]\n\nUn test doit correspondre aux spécifications de l'application, il faut donc écrire les tests en premier puis les faire passer par la suite plutôt que d'écrire le code avant et de prendre le risque d'être influencé par celui-ci lors de la rédaction des tests[\\[11\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-11). Bob Martin[\\[12\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-12), grand défenseur de la méthode [TDD](https:\/\/fr.wikipedia.org\/wiki\/Test_Driven_Development \"Test Driven Development\"), propose un [modèle](https:\/\/fr.wikipedia.org\/wiki\/Pattern \"Pattern\") simple pour l'écriture des tests unitaires :\n\n1. Écrire une fonction de test qui doit obtenir un résultat défini dans les spécifications. Ce code appelant un code qui n'existe pas encore, celui-ci doit échouer. Ceci a pour but de définir une fonction qui teste « quelque chose ».\n2. Écrire le code (le minimum de « quelque chose ») pour faire réussir le test.\n3. Une fois le test en succès, rajouter un autre test pour obtenir un résultat légèrement différent, en faisant varier les entrées par exemple. Ce nouveau test fera faillir le code principal.\n4. Modifier le code principal pour faire réussir les tests.\n5. Recommencer, en éliminant et [refactorisant](https:\/\/fr.wikipedia.org\/wiki\/R%C3%A9usinage_de_code \"Réusinage de code\") les éventuelles redondances dans le code des tests. On refactorise en même temps le code principal que le code des tests.\n6. Un test unitaire doit tester une caractéristique et une seule. On ne définit pas un « [scénario](https:\/\/fr.wikipedia.org\/wiki\/Sc%C3%A9nario_\\(informatique\\) \"Scénario (informatique)\") » de test complexe dans un test unitaire.\n7. Il est déconseillé de tester les détails d'implémentation telles que les fonctions privées d'une classe, on se concentrera à tester les fonctions publiques, c'est-à-dire les interfaces avec lesquelles les acteurs extérieurs interagissent. Ainsi, on découple les tests de l'implémentation et on se concentre sur la vérification du comportement attendu tout en gardant une flexibilité sur la manière d'arriver au résultat souhaité.\n\n### Utiliser des mocks\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=9 \"Modifier la section : Utiliser des mocks\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=9 \"Modifier le code source de la section : Utiliser des mocks\")\\]\n\nLes [mocks](https:\/\/fr.wikipedia.org\/wiki\/Mock_\\(programmation_orient%C3%A9e_objet\\) \"Mock (programmation orientée objet)\") sont des objets permettant de simuler un objet réel de façon contrôlée. Dans certains cas, l'utilisation de mock est primordiale, pour un gain de temps de [couverture de code](https:\/\/fr.wikipedia.org\/wiki\/Couverture_de_code \"Couverture de code\"), et de fiabilité des tests[\\[13\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-13)\n\n- pour simuler une [base de données](https:\/\/fr.wikipedia.org\/wiki\/Base_de_donn%C3%A9es \"Base de données\"), un [service web](https:\/\/fr.wikipedia.org\/wiki\/Service_web \"Service web\"), etc., les interactions entre l'application et ces outils prennent du temps, l'utilisation de mock pour simuler leurs fonctionnements peut être un gain de temps considérable ;\n- certains cas d'erreurs sont très difficile à reproduire, l'utilisation de mock permet ici de simuler une erreur pour pouvoir traiter ce cas et donc améliorer la couverture de code, par exemple le catch d'une exception ;\n- sans l'utilisation de mock, le test peut retourner une erreur ne provenant pas du code qui est testé (par exemple une base de données).\n\nCependant, une utilisation abusive de mock peut avoir l'effet inverse, notamment allonger le temps d'exécution des tests, rendre les tests compliqués à comprendre et à maintenir.\n\n## Génération\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=10 \"Modifier la section : Génération\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=10 \"Modifier le code source de la section : Génération\")\\]\n\nLa plupart des [frameworks](https:\/\/fr.wikipedia.org\/wiki\/Framework \"Framework\") de la famille [xUnit](https:\/\/fr.wikipedia.org\/wiki\/XUnit \"XUnit\") permettent la génération des classes de test unitaire. Cependant ces frameworks ne fournissent que le squelette des classes. Les tests devront donc être écrits par le développeur.\n\nLa génération de tests unitaires est un sujet important pour les chercheurs et plusieurs conférences s'intéressent à cette problématique, telles que [International Symposium on Software Testing and Analysis](https:\/\/fr.wikipedia.org\/w\/index.php?title=International_Symposium_on_Software_Testing_and_Analysis&action=edit&redlink=1 \"International Symposium on Software Testing and Analysis (page inexistante)\") (ISSTA), [International Conference on Software Engineering](https:\/\/fr.wikipedia.org\/w\/index.php?title=International_Conference_on_Software_Engineering&action=edit&redlink=1 \"International Conference on Software Engineering (page inexistante)\") (ICSE) et [Automated Software Engineering](https:\/\/fr.wikipedia.org\/w\/index.php?title=Automated_Software_Engineering&action=edit&redlink=1 \"Automated Software Engineering (page inexistante)\") (ASE).\n\n### Correction de test unitaire\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=11 \"Modifier la section : Correction de test unitaire\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=11 \"Modifier le code source de la section : Correction de test unitaire\")\\]\n\nLors d'une modification dans le code d'un programme, il se peut que certains tests ne passent plus ; dans ce cas, le développeur doit déterminer si cela vient du code en lui-même ou du test : si cela vient du test, le développeur doit modifier son test car la suppression de celui-ci entraînerait une augmentation des chances de régression du programme. Certains chercheurs ont développé des outils pour résoudre ce problème.\n\nReAssert[\\[14\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-14) est un outil suggérant des réparations pour un test qui échoue, il analyse les tests à modifier et suggère des changements au développeur, si cette suggestion convient au développeur, il peut effectuer le changement en cliquant sur un bouton.\n\n### Test unitaire paramétrable\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=12 \"Modifier la section : Test unitaire paramétrable\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=12 \"Modifier le code source de la section : Test unitaire paramétrable\")\\]\n\nLes tests unitaires paramétrables sont des tests unitaires qui prennent des paramètres. Ils peuvent ensuite utiliser des outils comme QuickCheck pour générer des paramètres. Ces tests sont supportés par [JUnit](https:\/\/fr.wikipedia.org\/wiki\/JUnit \"JUnit\"), [TestNG](https:\/\/fr.wikipedia.org\/wiki\/TestNG \"TestNG\") et NUnit.\n\nEn s'appuyant sur des cas concrets d'entrée et sortie, la génération d'Oracle et sur la couverture de test pour minimiser les cas, des chercheurs ont réussi à générer des tests unitaires paramétrables[\\[15\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-15). Les résultats de cette méthode sont prometteurs.\n\n## Environnements de développement\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=13 \"Modifier la section : Environnements de développement\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=13 \"Modifier le code source de la section : Environnements de développement\")\\]\n\nIl existe une multitude de cadriciels (*[framework](https:\/\/fr.wikipedia.org\/wiki\/Framework \"Framework\")*) permettant de réaliser facilement des tests unitaires. Il en existe dans les principaux [langages de programmation](https:\/\/fr.wikipedia.org\/wiki\/Langage_de_programmation \"Langage de programmation\"). Par exemple `Test::More`[\\[16\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-16) pour le [Perl](https:\/\/fr.wikipedia.org\/wiki\/Langage_Perl \"Langage Perl\").\n\n### Frameworks xUnit\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=14 \"Modifier la section : Frameworks xUnit\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=14 \"Modifier le code source de la section : Frameworks xUnit\")\\]\n\nLe terme générique « [xUnit](https:\/\/fr.wikipedia.org\/wiki\/XUnit \"XUnit\") » désigne un outil permettant de réaliser des tests unitaires dans un langage donné (dont l'initiale remplace « x » le plus souvent).\n\n- AUnit[\\[17\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-17) pour [Ada](https:\/\/fr.wikipedia.org\/wiki\/Ada_\\(langage\\) \"Ada (langage)\") ;\n- ASUnit[\\[18\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-18) pour [ActionScript](https:\/\/fr.wikipedia.org\/wiki\/ActionScript \"ActionScript\") ;\n- Cppunit[\\[19\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-19) pour [C++](https:\/\/fr.wikipedia.org\/wiki\/C%2B%2B \"C++\") ;\n- CUnit[\\[20\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-20) pour [C](https:\/\/fr.wikipedia.org\/wiki\/C_\\(langage\\) \"C (langage)\") ;\n- DUnit pour [Delphi](https:\/\/fr.wikipedia.org\/wiki\/Embarcadero_Delphi \"Embarcadero Delphi\") ;\n- FLEXunit pour [Adobe Flex](https:\/\/fr.wikipedia.org\/wiki\/Adobe_Flex \"Adobe Flex\") ;\n- [Google](https:\/\/fr.wikipedia.org\/wiki\/Google \"Google\") Test[\\[21\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-21) et Boost Test[\\[22\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-22) pour [C++](https:\/\/fr.wikipedia.org\/wiki\/C%2B%2B \"C++\") ;\n- HUnit[\\[23\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-23) pour [Haskell](https:\/\/fr.wikipedia.org\/wiki\/Haskell \"Haskell\") ;\n- JSUnit[\\[24\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-24), QUnit[\\[25\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-25), [Unit.js](https:\/\/fr.wikipedia.org\/wiki\/Unit.js \"Unit.js\")[\\[26\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-26) et Jest[\\[27\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-27) pour [JavaScript](https:\/\/fr.wikipedia.org\/wiki\/JavaScript \"JavaScript\") ;\n- [JUnit](https:\/\/fr.wikipedia.org\/wiki\/JUnit \"JUnit\")[\\[28\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-28) et [TestNG](https:\/\/fr.wikipedia.org\/wiki\/TestNG \"TestNG\")[\\[29\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-29) pour [Java](https:\/\/fr.wikipedia.org\/wiki\/Java_\\(langage\\) \"Java (langage)\") ;\n- NUnit[\\[30\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-30) pour [.NET](https:\/\/fr.wikipedia.org\/wiki\/Microsoft_.NET \"Microsoft .NET\") ;\n- [Microsoft](https:\/\/fr.wikipedia.org\/wiki\/Microsoft \"Microsoft\") Unit Test[\\[31\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-31) pour [.NET](https:\/\/fr.wikipedia.org\/wiki\/Microsoft_.NET \"Microsoft .NET\") ;\n- xUnit[\\[32\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-32) pour [.NET](https:\/\/fr.wikipedia.org\/wiki\/Microsoft_.NET \"Microsoft .NET\") ;\n- NUnitASP[\\[33\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-33) pour [ASP.NET](https:\/\/fr.wikipedia.org\/wiki\/ASP.NET \"ASP.NET\") (support interrompu depuis le\n  31 janvier 2008\n  ) ;\n- OUnit[\\[34\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-34) pour [OCaml](https:\/\/fr.wikipedia.org\/wiki\/OCaml \"OCaml\") ;\n- OCunit pour [Objective C](https:\/\/fr.wikipedia.org\/wiki\/Objective_C \"Objective C\") ;\n- PBUnit pour [PowerBuilder](https:\/\/fr.wikipedia.org\/wiki\/PowerBuilder \"PowerBuilder\") ;\n- [PHPUnit](https:\/\/fr.wikipedia.org\/wiki\/PHPUnit \"PHPUnit\")[\\[35\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-35), SimpleTest[\\[36\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-36) et Atoum[\\[37\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-37) pour [PHP](https:\/\/fr.wikipedia.org\/wiki\/PHP \"PHP\") ;\n- plunit pour [Prolog](https:\/\/fr.wikipedia.org\/wiki\/Prolog \"Prolog\") ;\n- utPLSQL[\\[38\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-38) pour [PL\/SQL](https:\/\/fr.wikipedia.org\/wiki\/PL\/SQL \"PL\/SQL\") ;\n- Unittest et [PyUnit](https:\/\/fr.wikipedia.org\/wiki\/PyUnit \"PyUnit\") pour [Python](https:\/\/fr.wikipedia.org\/wiki\/Python_\\(langage\\) \"Python (langage)\") ;\n- [Tape](https:\/\/fr.wikipedia.org\/wiki\/Tape_\\(framework_de_tests_JavaScript\\) \"Tape (framework de tests JavaScript)\") pour [JavaScript](https:\/\/fr.wikipedia.org\/wiki\/JavaScript \"JavaScript\") ;\n- Test::Unit pour [Ruby](https:\/\/fr.wikipedia.org\/wiki\/Ruby \"Ruby\") ;\n- Test::More pour [Perl](https:\/\/fr.wikipedia.org\/wiki\/Langage_Perl \"Langage Perl\") ;\n- [Typemock](https:\/\/fr.wikipedia.org\/w\/index.php?title=Typemock&action=edit&redlink=1 \"Typemock (page inexistante)\") pour .NET, C++, C\\#. Avec Typemock vous pouvez travailler sur legacy code aussi.\n- SUnit[\\[39\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-39) pour [Smalltalk](https:\/\/fr.wikipedia.org\/wiki\/Smalltalk \"Smalltalk\") ;\n- RPGUnit[\\[40\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-40) pour RPG ;\n- ScalaTest pour Scala\n- SASUnit[\\[41\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-41) pour [SAS](https:\/\/fr.wikipedia.org\/wiki\/SAS_\\(langage\\) \"SAS (langage)\").\n\n## Outils commerciaux\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=15 \"Modifier la section : Outils commerciaux\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=15 \"Modifier le code source de la section : Outils commerciaux\")\\]\n\nDivers outils permettent l'automatisation des tests unitaires :\n\n- Le module TBrun de la suite d'outils [LDRA](https:\/\/fr.wikipedia.org\/wiki\/LDRA \"LDRA\") ;\n- Tessy (distribution : Hitex Development Tools\/Allemagne).\n- Ponicode, génération de tests unitaires en Javascript[\\[42\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-42).\n\n## Articles connexes\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=16 \"Modifier la section : Articles connexes\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=16 \"Modifier le code source de la section : Articles connexes\")\\]\n\nSur les autres projets Wikimedia :\n\n- [Test unitaire](https:\/\/fr.wikibooks.org\/wiki\/Introduction_au_test_logiciel\/Tests_unitaires \"b:Introduction au test logiciel\/Tests unitaires\"), sur Wikibooks\n\n- [Cycle en V](https:\/\/fr.wikipedia.org\/wiki\/Cycle_en_V \"Cycle en V\")\n- [Test](https:\/\/fr.wikipedia.org\/wiki\/Test_\\(informatique\\) \"Test (informatique)\")\n- [Extreme programming](https:\/\/fr.wikipedia.org\/wiki\/Extreme_programming \"Extreme programming\")\n- [Test Driven Development](https:\/\/fr.wikipedia.org\/wiki\/Test_Driven_Development \"Test Driven Development\")\n\n## Notes\n\\[[modifier](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&veaction=edit&section=17 \"Modifier la section : Notes\") \\| [modifier le code](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&action=edit&section=17 \"Modifier le code source de la section : Notes\")\\]\n\n1. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-1)\n   (en)\n   \n   Benington, Herbert D., «\n   \n   Production of large computer programs\n   \n   », *Proceedings of the Symposium on Advanced Programming Methods for Digital Computers, Washington, D.C., June 28-29, 1956*, Office of Naval Research, Department of the Navy,‎\n   \n   1956\n   \n   ,\n   \n   p.\n   \n   15-28\n2. ↑ [a](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-:0_2-0) et [b](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-:0_2-1)\n   H. D. Benington, «\n   \n   Production of large computer programs\n   \n   », *Proceedings of the 9th international conference on Software Engineering*, IEEE Computer Society Press, iCSE '87,‎\n   \n   1er\n   \n   mars 1987\n   \n   ,\n   \n   p.\n   \n   299–310\n   \n   ([ISBN](https:\/\/fr.wikipedia.org\/wiki\/International_Standard_Book_Number \"International Standard Book Number\") [978-0-89791-216-7](https:\/\/fr.wikipedia.org\/wiki\/Sp%C3%A9cial:Ouvrages_de_r%C3%A9f%C3%A9rence\/978-0-89791-216-7 \"Spécial:Ouvrages de référence\/978-0-89791-216-7\"), [DOI](https:\/\/fr.wikipedia.org\/wiki\/Digital_Object_Identifier \"Digital Object Identifier\") [10\\.5555\/41765.41799](https:\/\/dx.doi.org\/10.5555\/41765.41799), [lire en ligne](https:\/\/dl.acm.org\/doi\/10.5555\/41765.41799), consulté le\n   \n   3 avril 2024\n   \n   )\n3. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-3)\n   Norman A. Zimmerman, «\n   \n   System integration as a programming function\n   \n   », *Proceedings of the 1969 24th national conference*, Association for Computing Machinery, aCM '69,‎\n   \n   26 août 1969\n   \n   ,\n   \n   p.\n   \n   459–467\n   \n   ([ISBN](https:\/\/fr.wikipedia.org\/wiki\/International_Standard_Book_Number \"International Standard Book Number\") [978-1-4503-7493-4](https:\/\/fr.wikipedia.org\/wiki\/Sp%C3%A9cial:Ouvrages_de_r%C3%A9f%C3%A9rence\/978-1-4503-7493-4 \"Spécial:Ouvrages de référence\/978-1-4503-7493-4\"), [DOI](https:\/\/fr.wikipedia.org\/wiki\/Digital_Object_Identifier \"Digital Object Identifier\") [10\\.1145\/800195.805951](https:\/\/dx.doi.org\/10.1145\/800195.805951), [lire en ligne](https:\/\/dl.acm.org\/doi\/10.1145\/800195.805951), consulté le\n   \n   3 avril 2024\n   \n   )\n4. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-4)\n   (en)\n   \n   Gouvernement des Etats Unis d'Amérique, Département de la Défence,\n   \n   MIL-STD-483 Military standard: configuration management practices for systems, equipment, munitions, and computer programs\n   \n   ,\n   \n   31 décembre 1970\n   \n   , Section 3.4.7.2. \"The contractor shall then code and test software Units, and enter the source and object code, and associated listings of each successfully tested Unit into the Developmental Configuration\"\n5. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-5)\n   (en)\n   \n   Michael F. Tighe, «\n   \n   The value of a proper software quality assurance methodology\n   \n   », *ACM SIGMETRICS Performance Evaluation Review*,\n   \n   vol.\n   \n   7,\n   \n   nos\n   \n   3-4,‎\n   \n   novembre 1978\n   \n   ,\n   \n   p.\n   \n   165–172\n   \n   ([ISSN](https:\/\/fr.wikipedia.org\/wiki\/International_Standard_Serial_Number \"International Standard Serial Number\") [0163-5999](https:\/\/portal.issn.org\/resource\/issn\/0163-5999), [DOI](https:\/\/fr.wikipedia.org\/wiki\/Digital_Object_Identifier \"Digital Object Identifier\") [10\\.1145\/1007775.811118](https:\/\/dx.doi.org\/10.1145\/1007775.811118), [lire en ligne](https:\/\/dl.acm.org\/doi\/10.1145\/1007775.811118), consulté le\n   \n   3 avril 2024\n   \n   )\n6. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-6) [Camp Smalltalk SUnit](http:\/\/sunit.sourceforge.net\/)\n7. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-7) *[Simple Smalltalk Testing:With Patterns](http:\/\/www.xprogramming.com\/testfram.htm)*, in *Smalltalk Report* octobre 1994, Kent Beck\n8. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-8)\n   (en)\n   \n   Ward Cunningham, «\n   \n   [Testing Framework](http:\/\/wiki.c2.com\/?TestingFramework)\n   \n   » ![Accès libre](https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/6\/65\/Lock-green.svg\/20px-Lock-green.svg.png), sur wiki.c2.com\n   \n   .\n9. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-9) [Xunit, Martin Fowler](http:\/\/www.martinfowler.com\/bliki\/Xunit.html)\n10. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-10) GNU Based Compilation System for Space Embedded Applications, Blondin, J. P. & Martignano, M., DASIA 98 - Data Systems in Aerospace, Proceedings of the conference held 25-28 May, 1998 in Athens, Greece, Edited by B. Kaldeich-Schü.rmann. ESA SP-422. Paris: European Space Agency, 1998., p.137, \"1998ESASP.422..137B\", page 138 <http:\/\/adsbit.harvard.edu\/\/full\/1998ESASP.422..137B\/0000138.000.html>\n11. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-11) [Unit Testing Best Practices, Roy Osherove](https:\/\/fr.wikipedia.org\/wiki\/Programmation_informatique \"Programmation informatique\").\n12. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-12) [Test First, bob Martin](http:\/\/blog.8thlight.com\/uncle-bob\/2013\/09\/23\/Test-first.html).\n13. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-13) Robert Martin, *When to Mock*.\n14. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-14)\n    (en)\n    \n    Brett Daniel, Danny Dig, Tihomir Gvero, Vilas Jagannath, Johnston Jiaa, Damion Mitchell, Jurand Nogiec, Shin Hwei Tan et Darko Marinov, «\n    \n    *ReAssert: a tool for repairing broken unit tests*\n    \n    », *ICSE*,‎\n    \n    2011\n    \n    ([lire en ligne](http:\/\/dl.acm.org\/citation.cfm?doid=1985793.1985978))\n    \n    .\n15. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-15)\n    (en)\n    \n    Gordon Fraser et Andreas Zeller, «\n    \n    Generating Parameterized Unit Tests\n    \n    », *ISSTA*,‎\n    \n    2011\n    \n    ([lire en ligne](http:\/\/dl.acm.org\/citation.cfm?doid=2001420.2001464))\n    \n    .\n16. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-16) [Test::More sur CPAN](https:\/\/metacpan.org\/module\/Test::More), entre autres [modules de tests](https:\/\/metacpan.org\/search?q=Test). Voir aussi les articles de l'association des *mongueurs de Perl* dans [Linux Magazine France](https:\/\/fr.wikipedia.org\/wiki\/Linux_Magazine_France \"Linux Magazine France\") disponibles sur <http:\/\/articles.mongueurs.net\/magazines>\n17. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-17) [AUnit](https:\/\/libre.adacore.com\/aunit\/main.html)\n18. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-18) [AsUnit](http:\/\/www.asunit.org\/)\n19. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-19) [CppUnit](http:\/\/cppunit.sourceforge.net\/) et en [version 2](https:\/\/launchpad.net\/cppunit2)\n20. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-20) [CUnit](http:\/\/cunit.sourceforge.net\/)\n21. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-21) [GoogleTest](https:\/\/code.google.com\/p\/googletest\/)\n22. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-22) [Boost.Test](http:\/\/www.boost.org\/doc\/libs\/release\/libs\/test\/index.html)\n23. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-23) [HUnit](http:\/\/hunit.sourceforge.net\/)\n24. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-24) [JsUnit](http:\/\/www.jsunit.net\/)\n25. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-25) <http:\/\/qunitjs.com> Unit testing for Javascript made by the jQuery Foundation\n26. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-26)\n    (en)\n    \n    [Unit JS](http:\/\/unitjs.com\/) : « Unit testing framework for Javascript ».\n27. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-27)\n    (en)\n    \n    «\n    \n    [Jest · 🃏 Delightful JavaScript Testing](https:\/\/jestjs.io\/)\n    \n    », sur jestjs.io\n    \n    (consulté le\n    \n    2 mars 2020\n    \n    )\n    \n    .\n28. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-28) [Welcome to The New JUnit.org! \\| JUnit.org](http:\/\/junit.org\/).\n29. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-29)\n    (en)\n    \n    «\n    \n    [TestNG Documentation](http:\/\/testng.org\/)\n    \n    », sur testng.org\n    \n    (consulté le\n    \n    21 mai 2024\n    \n    )\n    \n    .\n30. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-30) [NUnit - Home](http:\/\/www.nunit.org\/)\n31. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-31)\n    (en-US)\n    \n    erickson-doug, «\n    \n    [Writing Unit Tests for the .NET Framework with the Microsoft Unit Test Framework for Managed Code - Visual Studio](https:\/\/docs.microsoft.com\/fr-fr\/visualstudio\/test\/writing-unit-tests-for-the-dotnet-framework-with-the-microsoft-unit-test-framework-for-managed-code?view=vs-2015)\n    \n    », sur docs.microsoft.com\n    \n    (consulté le\n    \n    4 septembre 2018\n    \n    )\n    \n    .\n32. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-32)\n    (en)\n    \n    «\n    \n    [Home \\> xUnit.net](https:\/\/xunit.github.io\/)\n    \n    », sur xunit.github.io\n    \n    (consulté le\n    \n    4 septembre 2018\n    \n    )\n    \n    .\n33. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-33) [NUnitAsp - ASP.NET unit testing](http:\/\/nunitasp.sourceforge.net\/)\n34. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-34) [OUnit](http:\/\/ounit.forge.ocamlcore.org\/)\n35. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-35) [PHPUnit - Trac](https:\/\/www.phpunit.de\/)\n36. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-36) [SimpleTest - Unit Testing for PHP](http:\/\/www.simpletest.org\/)\n37. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-37) [Atoum](http:\/\/www.atoum.org\/)\n38. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-38) [utPLSQL](http:\/\/utplsql.sourceforge.net\/)\n39. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-39) [Simple Smalltalk Testing: With Patterns](http:\/\/www.xprogramming.com\/testfram.htm)\n40. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-40) <http:\/\/rpgunit.sourceforge.net\/>\n41. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-41)\n    (en)\n    \n    «\n    \n    [SASUnit](https:\/\/sourceforge.net\/projects\/sasunit\/)\n    \n    », sur SourceForge\n    \n    (consulté le\n    \n    24 février 2020\n    \n    )\n    \n    .\n42. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-42)\n    (en)\n    \n    «\n    \n    [Ponicode - Quick and easy Javascript unit testing](https:\/\/ponicode.com\/)\n    \n    », sur ponicode.com\n    \n    (consulté le\n    \n    23 juin 2020\n    \n    )\n    \n    .\n\n| [v](https:\/\/fr.wikipedia.org\/wiki\/Mod%C3%A8le:Palette_Qualit%C3%A9_logicielle \"Modèle:Palette Qualité logicielle\") · [m](https:\/\/fr.wikipedia.org\/w\/index.php?title=Mod%C3%A8le:Palette_Qualit%C3%A9_logicielle&action=edit)Gestion de la [qualité logicielle](https:\/\/fr.wikipedia.org\/wiki\/Qualit%C3%A9_logicielle \"Qualité logicielle\") |   |\n|---|---|\n| [Indicateurs de qualité](https:\/\/fr.wikipedia.org\/wiki\/Qualit%C3%A9_logicielle#Indicateurs_de_qualit%C3%A9_logicielle \"Qualité logicielle\") ([ISO\/CEI 9126](https:\/\/fr.wikipedia.org\/wiki\/ISO\/CEI_9126 \"ISO\/CEI 9126\")) | Capacité fonctionnelle (réponse aux [exigences](https:\/\/fr.wikipedia.org\/wiki\/Exigence_\\(ing%C3%A9nierie\\) \"Exigence (ingénierie)\")) [Fiabilité](https:\/\/fr.wikipedia.org\/wiki\/Fiabilit%C3%A9 \"Fiabilité\") [Maintenabilité](https:\/\/fr.wikipedia.org\/wiki\/Maintenabilit%C3%A9 \"Maintenabilité\") [Performance](https:\/\/fr.wikipedia.org\/wiki\/Performances_\\(informatique\\) \"Performances (informatique)\") [Portabilité](https:\/\/fr.wikipedia.org\/wiki\/Portabilit%C3%A9_\\(informatique\\) \"Portabilité (informatique)\") [Utilisabilité](https:\/\/fr.wikipedia.org\/wiki\/Utilisabilit%C3%A9 \"Utilisabilité\") |\n| Compréhension et contrôle du [code source](https:\/\/fr.wikipedia.org\/wiki\/Code_source \"Code source\") |   |\n|   |   |\n| [Tests](https:\/\/fr.wikipedia.org\/wiki\/Test_\\(informatique\\) \"Test (informatique)\") | [Acceptation](https:\/\/fr.wikipedia.org\/wiki\/Test_d%27acceptation \"Test d'acceptation\") [Intégration](https:\/\/fr.wikipedia.org\/wiki\/Test_d%27int%C3%A9gration \"Test d'intégration\") [Performance](https:\/\/fr.wikipedia.org\/wiki\/Test_de_performance \"Test de performance\") [Régression](https:\/\/fr.wikipedia.org\/wiki\/Test_de_r%C3%A9gression \"Test de régression\") [Unitaire]() [Utilisateur](https:\/\/fr.wikipedia.org\/wiki\/Test_utilisateur \"Test utilisateur\") [Validation](https:\/\/fr.wikipedia.org\/wiki\/Test_de_validation \"Test de validation\") |\n| [Métriques](https:\/\/fr.wikipedia.org\/wiki\/M%C3%A9trique_\\(logiciel\\) \"Métrique (logiciel)\") | [Cohésion](https:\/\/fr.wikipedia.org\/wiki\/Coh%C3%A9sion_\\(informatique\\) \"Cohésion (informatique)\") [Couplage](https:\/\/fr.wikipedia.org\/wiki\/Couplage_\\(informatique\\) \"Couplage (informatique)\") [Couverture de code](https:\/\/fr.wikipedia.org\/wiki\/Couverture_de_code \"Couverture de code\") [Halstead](https:\/\/fr.wikipedia.org\/wiki\/M%C3%A9triques_d%27Halstead \"Métriques d'Halstead\") [Indépendance fonctionnelle](https:\/\/fr.wikipedia.org\/wiki\/Ind%C3%A9pendance_fonctionnelle \"Indépendance fonctionnelle\") [Indice de maintenabilité](https:\/\/fr.wikipedia.org\/wiki\/Indice_de_maintenabilit%C3%A9 \"Indice de maintenabilité\") [Ligne de code](https:\/\/fr.wikipedia.org\/wiki\/Ligne_de_code \"Ligne de code\") [Nombre cyclomatique](https:\/\/fr.wikipedia.org\/wiki\/Nombre_cyclomatique \"Nombre cyclomatique\") [Point de fonction](https:\/\/fr.wikipedia.org\/wiki\/Point_de_fonction \"Point de fonction\") |\n| Remaniements | [Maintenance](https:\/\/fr.wikipedia.org\/wiki\/Maintenance_du_logiciel \"Maintenance du logiciel\") [Optimisation de code](https:\/\/fr.wikipedia.org\/wiki\/Optimisation_de_code \"Optimisation de code\") [Réusinage de code](https:\/\/fr.wikipedia.org\/wiki\/R%C3%A9usinage_de_code \"Réusinage de code\") ([Règle de trois](https:\/\/fr.wikipedia.org\/wiki\/R%C3%A8gle_de_trois_\\(programmation_informatique\\) \"Règle de trois (programmation informatique)\")) |\n| Principes de [programmation](https:\/\/fr.wikipedia.org\/wiki\/Programmation_informatique \"Programmation informatique\") |   |\n|   |   |\n| [SOLID](https:\/\/fr.wikipedia.org\/wiki\/SOLID_\\(informatique\\) \"SOLID (informatique)\") | [Responsabilité unique](https:\/\/fr.wikipedia.org\/wiki\/Principe_de_responsabilit%C3%A9_unique \"Principe de responsabilité unique\") [Ouvert\/fermé](https:\/\/fr.wikipedia.org\/wiki\/Principe_ouvert\/ferm%C3%A9 \"Principe ouvert\/fermé\") [Substitution de Liskov](https:\/\/fr.wikipedia.org\/wiki\/Principe_de_substitution_de_Liskov \"Principe de substitution de Liskov\") [Ségrégation des interfaces](https:\/\/fr.wikipedia.org\/wiki\/Principe_de_s%C3%A9gr%C3%A9gation_des_interfaces \"Principe de ségrégation des interfaces\") [Inversion des dépendances](https:\/\/fr.wikipedia.org\/wiki\/Inversion_des_d%C3%A9pendances \"Inversion des dépendances\") |\n| Mauvaises pratiques |   |\n|   |   |\n| [Antipatterns](https:\/\/fr.wikipedia.org\/wiki\/Antipattern \"Antipattern\") | [Attente active](https:\/\/fr.wikipedia.org\/wiki\/Attente_active \"Attente active\") [Grosse boule de boue](https:\/\/fr.wikipedia.org\/wiki\/Grosse_boule_de_boue \"Grosse boule de boue\") [Programmation spaghetti](https:\/\/fr.wikipedia.org\/wiki\/Programmation_spaghetti \"Programmation spaghetti\") ([syndrome](https:\/\/fr.wikipedia.org\/wiki\/Syndrome_du_plat_de_spaghettis \"Syndrome du plat de spaghettis\")) [Réinventer la roue](https:\/\/fr.wikipedia.org\/wiki\/R%C3%A9inventer_la_roue \"Réinventer la roue\") |\n|   |   |\n| [Code smells](https:\/\/fr.wikipedia.org\/wiki\/Code_smell \"Code smell\") | [Duplication de code](https:\/\/fr.wikipedia.org\/wiki\/Duplication_de_code \"Duplication de code\") [God object](https:\/\/fr.wikipedia.org\/wiki\/God_object \"God object\") |\n| Voir aussi : [Génie logiciel](https:\/\/fr.wikipedia.org\/wiki\/G%C3%A9nie_logiciel \"Génie logiciel\"), [Software craftsmanship](https:\/\/fr.wikipedia.org\/wiki\/Software_craftsmanship \"Software craftsmanship\"), [Dégradation logicielle](https:\/\/fr.wikipedia.org\/wiki\/D%C3%A9gradation_logicielle \"Dégradation logicielle\") |   |\n\n- [![icône décorative](https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/0\/02\/Circle-icons-computer.svg\/40px-Circle-icons-computer.svg.png)](https:\/\/fr.wikipedia.org\/wiki\/Portail:Informatique \"Portail de l’informatique\") [Portail de l’informatique](https:\/\/fr.wikipedia.org\/wiki\/Portail:Informatique \"Portail:Informatique\")\n\n![](https:\/\/fr.wikipedia.org\/wiki\/Special:CentralAutoLogin\/start?useformat=desktop&type=1x1&usesul3=1)\n\nCe document provient de « <https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&oldid=233485497> ».\n\n[Catégorie](https:\/\/fr.wikipedia.org\/wiki\/Cat%C3%A9gorie:Accueil \"Catégorie:Accueil\") :\n\n- [Test logiciel](https:\/\/fr.wikipedia.org\/wiki\/Cat%C3%A9gorie:Test_logiciel \"Catégorie:Test logiciel\")\n\nCatégories cachées :\n\n- [Portail:Informatique\/Articles liés](https:\/\/fr.wikipedia.org\/wiki\/Cat%C3%A9gorie:Portail:Informatique\/Articles_li%C3%A9s \"Catégorie:Portail:Informatique\/Articles liés\")\n- [Portail:Technologies\/Articles liés](https:\/\/fr.wikipedia.org\/wiki\/Cat%C3%A9gorie:Portail:Technologies\/Articles_li%C3%A9s \"Catégorie:Portail:Technologies\/Articles liés\")\n\n- La dernière modification de cette page a été faite le 21 février 2026 à 12:01.\n- [Droit d'auteur](https:\/\/fr.wikipedia.org\/wiki\/Wikip%C3%A9dia:Citation_et_r%C3%A9utilisation_du_contenu_de_Wikip%C3%A9dia \"Wikipédia:Citation et réutilisation du contenu de Wikipédia\") : les textes sont disponibles sous [licence Creative Commons attribution, partage dans les mêmes conditions](https:\/\/creativecommons.org\/licenses\/by-sa\/4.0\/deed.fr) ; d’autres conditions peuvent s’appliquer. Voyez les [conditions d’utilisation](https:\/\/foundation.wikimedia.org\/wiki\/Policy:Terms_of_Use\/fr) pour plus de détails, ainsi que les [crédits graphiques](https:\/\/fr.wikipedia.org\/wiki\/Wikip%C3%A9dia:Cr%C3%A9dits_graphiques \"Wikipédia:Crédits graphiques\"). En cas de réutilisation des textes de cette page, voyez [comment citer les auteurs et mentionner la licence](https:\/\/fr.wikipedia.org\/wiki\/Sp%C3%A9cial:Citer\/Test_unitaire \"Spécial:Citer\/Test unitaire\").  \n   Wikipedia® est une marque déposée de la [Wikimedia Foundation, Inc.](https:\/\/wikimediafoundation.org\/), organisation de bienfaisance régie par le paragraphe [501(c)(3)](https:\/\/fr.wikipedia.org\/wiki\/501c \"501c\") du code fiscal des États-Unis.\n\n- [Politique de confidentialité](https:\/\/foundation.wikimedia.org\/wiki\/Special:MyLanguage\/Policy:Privacy_policy\/fr)\n- [À propos de Wikipédia](https:\/\/fr.wikipedia.org\/wiki\/Wikip%C3%A9dia:%C3%80_propos_de_Wikip%C3%A9dia)\n- [Avertissements](https:\/\/fr.wikipedia.org\/wiki\/Wikip%C3%A9dia:Avertissements_g%C3%A9n%C3%A9raux)\n- [Contact](https:\/\/fr.wikipedia.org\/wiki\/Wikip%C3%A9dia:Contact)\n- [Contacts juridiques & sécurité](https:\/\/foundation.wikimedia.org\/wiki\/Special:MyLanguage\/Legal:Wikimedia_Foundation_Legal_and_Safety_Contact_Information)\n- [Code de conduite](https:\/\/foundation.wikimedia.org\/wiki\/Special:MyLanguage\/Policy:Universal_Code_of_Conduct)\n- [Développeurs](https:\/\/developer.wikimedia.org\/)\n- [Statistiques](https:\/\/stats.wikimedia.org\/#\/fr.wikipedia.org)\n- [Déclaration sur les témoins (cookies)](https:\/\/foundation.wikimedia.org\/wiki\/Special:MyLanguage\/Policy:Cookie_statement)\n- [Version mobile](https:\/\/fr.wikipedia.org\/w\/index.php?title=Test_unitaire&mobileaction=toggle_view_mobile)\n\n- [![Wikimedia Foundation](https:\/\/fr.wikipedia.org\/static\/images\/footer\/wikimedia.svg)](https:\/\/www.wikimedia.org\/)\n- [![Powered by MediaWiki](https:\/\/fr.wikipedia.org\/w\/resources\/assets\/mediawiki_compact.svg)](https:\/\/www.mediawiki.org\/)\n\nRechercher\n\nBasculer la table des matières\n\nTest unitaire\n\n29 langues\n\n[Ajouter un sujet](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire)","attrs_readable_markdown":"Un article de Wikipédia, l'encyclopédie libre.\n\nEn [programmation informatique](https:\/\/fr.wikipedia.org\/wiki\/Programmation_informatique \"Programmation informatique\"), le **test unitaire** (ou **TU**, voire ***UT*** pour *Unit Testing* en anglais) est une procédure permettant de vérifier le bon fonctionnement d'une partie précise d'un [logiciel](https:\/\/fr.wikipedia.org\/wiki\/Logiciel \"Logiciel\") ou d'une portion d'un [programme](https:\/\/fr.wikipedia.org\/wiki\/Programme_informatique \"Programme informatique\") (appelée « unité » ou « module »).\n\nDans les applications non critiques, l'écriture des tests unitaires a longtemps été considérée comme une tâche secondaire. Cependant, les méthodes [extreme programming](https:\/\/fr.wikipedia.org\/wiki\/Extreme_programming \"Extreme programming\") (XP) et [test driven development](https:\/\/fr.wikipedia.org\/wiki\/Test_driven_development \"Test driven development\") (TDD) ont remis les tests unitaires, appelés « tests du programmeur », au centre de l'activité de programmation.\n\nLes tests unitaires, en tant que principe de tester séparément des parties plus élémentaires d'un logiciel complexe, remonte aux débuts de l'[ingénierie logicielle](https:\/\/fr.wikipedia.org\/wiki\/Ing%C3%A9nierie_logicielle \"Ingénierie logicielle\"). En Juin 1956, H.D. Benington présente en effet le projet [SAGE](https:\/\/fr.wikipedia.org\/wiki\/Semi-Automatic_Ground_Environment \"Semi-Automatic Ground Environment\") au symposium sur les méthodes de programmation avancée organisé par la [marine américaine](https:\/\/fr.wikipedia.org\/wiki\/United_States_Navy \"United States Navy\"). L'approche utilisée prévoyait à l'issue de la phase de codage une étape de « tests de paramètres » pour valider la conformité des sous-programmes et composants à leur spécifications, avant de procéder à un « test d'assemblage » de ces composants[\\[1\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-1),[\\[2\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-:0-2).\n\nEn 1964, une approche similaire est décrite pour les logiciels du [programme Mercury](https:\/\/fr.wikipedia.org\/wiki\/Programme_Mercury \"Programme Mercury\") : les unités individuelles développées par différentes organisations étaient soumises à des \"tests unitaires\" avant d'être intégrées entre elles. En 1969, les méthodologies de tests sont structurées encore davantage, avec des tests unitaires, des tests de composants, et des [tests d'intégration](https:\/\/fr.wikipedia.org\/wiki\/Test_d%27int%C3%A9gration \"Test d'intégration\"), dans le but de valider des parties élémentaires du logiciel séparément, puis de vérifier le bon fonctionnement des assemblages progressif en blocs plus larges[\\[3\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-3). Des normes publiques adoptées à la fin des années 60, telles que les standards militaires MIL-STD-483[\\[4\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-4) et MIL-STD-490 de l'armée américaine contribuent à une large reconnaissance et adoption des tests unitaires au sein de gros projets.\n\nLes tests unitaires étaient alors interactifs[\\[2\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-:0-2), ou automatisés[\\[5\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-5), utilisant soit des tests programmés ou des outils de capture et répétition automatisés. En 1994 [Kent Beck](https:\/\/fr.wikipedia.org\/wiki\/Kent_Beck \"Kent Beck\") décrit un environnement cadre de test pour le langage [Smalltalk](https:\/\/fr.wikipedia.org\/wiki\/Smalltalk \"Smalltalk\"), qui deviendra [SUnit](https:\/\/fr.wikipedia.org\/w\/index.php?title=SUnit&action=edit&redlink=1 \"SUnit (page inexistante)\")[\\[6\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-6) par la suite[\\[7\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-7),[\\[8\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-8). En 1997, [Kent Beck](https:\/\/fr.wikipedia.org\/wiki\/Kent_Beck \"Kent Beck\") rencontre [Erich Gamma](https:\/\/fr.wikipedia.org\/wiki\/Erich_Gamma \"Erich Gamma\") avec lequel il crée [JUnit](https:\/\/fr.wikipedia.org\/wiki\/JUnit \"JUnit\") qui, par sa popularité, entraînera la création de nombreux [frameworks](https:\/\/fr.wikipedia.org\/wiki\/Frameworks \"Frameworks\") de tests unitaires, cet ensemble se nomme [xUnit](https:\/\/fr.wikipedia.org\/wiki\/XUnit \"XUnit\")[\\[9\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-9).\n\nÀ la même époque, ATTOL Unit test est développé, puis utilisé par [Sextant Avionique](https:\/\/fr.wikipedia.org\/wiki\/Sextant_Avionique \"Sextant Avionique\") en 1998[\\[10\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-10)\n\nOn écrit un test pour confronter une réalisation à sa [spécification](https:\/\/fr.wikipedia.org\/wiki\/Sp%C3%A9cification_fonctionnelle \"Spécification fonctionnelle\"). Le [test](https:\/\/fr.wikipedia.org\/wiki\/Test_\\(informatique\\) \"Test (informatique)\") définit un critère d'arrêt (état ou sorties à l'issue de l'exécution) et permet de statuer sur le succès ou sur l'échec d'une vérification. Grâce à la spécification, on est en mesure de faire correspondre un état d'entrée donné à un résultat ou à une sortie. Le [test](https:\/\/fr.wikipedia.org\/wiki\/Test_\\(informatique\\) \"Test (informatique)\") permet de vérifier que la relation d'entrée \/ sortie donnée par la spécification est bel et bien réalisée.\n\nLa méthode XP préconise d'écrire les tests en même temps, ou même avant la fonction à tester ([Test Driven Development](https:\/\/fr.wikipedia.org\/wiki\/Test_Driven_Development \"Test Driven Development\")). Ceci permet de définir précisément l'interface du module à développer. Les tests sont exécutés durant tout le développement, permettant de visualiser si le code fraîchement écrit correspond au besoin.\n\nLors d'une modification d'un programme, les tests unitaires signalent les éventuelles [régressions](https:\/\/fr.wikipedia.org\/wiki\/Test_de_r%C3%A9gression \"Test de régression\"). En effet, certains tests peuvent échouer à la suite d'une modification, il faut donc soit réécrire le test pour le faire correspondre aux nouvelles attentes, soit corriger l'erreur se situant dans le code.\n\nLes tests unitaires peuvent servir de complément à [l'API](https:\/\/fr.wikipedia.org\/wiki\/Interface_de_programmation \"Interface de programmation\"), il est très utile de lire les tests pour comprendre comment s'utilise une méthode. De plus, il est possible que la documentation ne soit plus à jour, mais les tests eux correspondent à la réalité de l'application.\n\nOn définit généralement 4 phases dans l'exécution d'un test unitaire :\n\n1. **Initialisation** (fonction `setUp`) : définition d'un environnement de test complètement reproductible (une [fixture](https:\/\/fr.wikipedia.org\/wiki\/Test_fixture \"Test fixture\")).\n2. **Exercice** : le module à tester est exécuté.\n3. **Vérification** (utilisation de fonctions `assert`) : comparaison des résultats obtenus avec un vecteur de résultat défini. Ces tests définissent le résultat du test : SUCCÈS (`SUCCESS`) ou ÉCHEC (`FAILURE`). On peut également définir d'autres résultats comme ÉVITÉ (`SKIPPED`).\n4. **Désactivation** (fonction `tearDown`) : désinstallation des [fixtures](https:\/\/fr.wikipedia.org\/wiki\/Test_fixture \"Test fixture\") pour retrouver l'état initial du système, dans le but de ne pas polluer les tests suivants. Tous les tests doivent être indépendants et reproductibles unitairement (quand exécutés seuls).\n\nIl s'agit pour le programmeur de tester un [module](https:\/\/fr.wikipedia.org\/wiki\/Module_\\(programmation\\) \"Module (programmation)\"), indépendamment du reste du programme, ceci afin de s'assurer qu'il réponde aux [spécifications fonctionnelles](https:\/\/fr.wikipedia.org\/wiki\/Sp%C3%A9cification_\\(informatique\\) \"Spécification (informatique)\") et qu'il fonctionne correctement en toutes circonstances. Cette vérification est considérée comme essentielle, en particulier dans les applications critiques. Elle s'accompagne couramment d'une vérification de la [couverture de code](https:\/\/fr.wikipedia.org\/wiki\/Couverture_de_code \"Couverture de code\") (évaluation de la couverture structurelle), qui consiste à s'assurer que l'ensemble des [tests](https:\/\/fr.wikipedia.org\/wiki\/Test_\\(informatique\\) \"Test (informatique)\") conduit à exécuter l'ensemble (ou une fraction déterminée) des instructions présentes dans le code.\n\nL'ensemble des tests unitaires doit être rejoué après une modification du code afin de vérifier qu'il n'y a pas de [régressions](https:\/\/fr.wikipedia.org\/wiki\/Non-r%C3%A9gression \"Non-régression\") (l'apparition de nouveaux dysfonctionnements). L'emploi d'une « stratégie de test » particulière *peut* limiter les tests à rejouer, par exemple : une analyse d'impact des modifications, corrélée à une preuve d'indépendance des modules, permet de cibler les cas de test unitaire à rejouer.\n\nUn test doit correspondre aux spécifications de l'application, il faut donc écrire les tests en premier puis les faire passer par la suite plutôt que d'écrire le code avant et de prendre le risque d'être influencé par celui-ci lors de la rédaction des tests[\\[11\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-11). Bob Martin[\\[12\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-12), grand défenseur de la méthode [TDD](https:\/\/fr.wikipedia.org\/wiki\/Test_Driven_Development \"Test Driven Development\"), propose un [modèle](https:\/\/fr.wikipedia.org\/wiki\/Pattern \"Pattern\") simple pour l'écriture des tests unitaires :\n\n1. Écrire une fonction de test qui doit obtenir un résultat défini dans les spécifications. Ce code appelant un code qui n'existe pas encore, celui-ci doit échouer. Ceci a pour but de définir une fonction qui teste « quelque chose ».\n2. Écrire le code (le minimum de « quelque chose ») pour faire réussir le test.\n3. Une fois le test en succès, rajouter un autre test pour obtenir un résultat légèrement différent, en faisant varier les entrées par exemple. Ce nouveau test fera faillir le code principal.\n4. Modifier le code principal pour faire réussir les tests.\n5. Recommencer, en éliminant et [refactorisant](https:\/\/fr.wikipedia.org\/wiki\/R%C3%A9usinage_de_code \"Réusinage de code\") les éventuelles redondances dans le code des tests. On refactorise en même temps le code principal que le code des tests.\n6. Un test unitaire doit tester une caractéristique et une seule. On ne définit pas un « [scénario](https:\/\/fr.wikipedia.org\/wiki\/Sc%C3%A9nario_\\(informatique\\) \"Scénario (informatique)\") » de test complexe dans un test unitaire.\n7. Il est déconseillé de tester les détails d'implémentation telles que les fonctions privées d'une classe, on se concentrera à tester les fonctions publiques, c'est-à-dire les interfaces avec lesquelles les acteurs extérieurs interagissent. Ainsi, on découple les tests de l'implémentation et on se concentre sur la vérification du comportement attendu tout en gardant une flexibilité sur la manière d'arriver au résultat souhaité.\n\nLes [mocks](https:\/\/fr.wikipedia.org\/wiki\/Mock_\\(programmation_orient%C3%A9e_objet\\) \"Mock (programmation orientée objet)\") sont des objets permettant de simuler un objet réel de façon contrôlée. Dans certains cas, l'utilisation de mock est primordiale, pour un gain de temps de [couverture de code](https:\/\/fr.wikipedia.org\/wiki\/Couverture_de_code \"Couverture de code\"), et de fiabilité des tests[\\[13\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-13)\n\n- pour simuler une [base de données](https:\/\/fr.wikipedia.org\/wiki\/Base_de_donn%C3%A9es \"Base de données\"), un [service web](https:\/\/fr.wikipedia.org\/wiki\/Service_web \"Service web\"), etc., les interactions entre l'application et ces outils prennent du temps, l'utilisation de mock pour simuler leurs fonctionnements peut être un gain de temps considérable ;\n- certains cas d'erreurs sont très difficile à reproduire, l'utilisation de mock permet ici de simuler une erreur pour pouvoir traiter ce cas et donc améliorer la couverture de code, par exemple le catch d'une exception ;\n- sans l'utilisation de mock, le test peut retourner une erreur ne provenant pas du code qui est testé (par exemple une base de données).\n\nCependant, une utilisation abusive de mock peut avoir l'effet inverse, notamment allonger le temps d'exécution des tests, rendre les tests compliqués à comprendre et à maintenir.\n\nLa plupart des [frameworks](https:\/\/fr.wikipedia.org\/wiki\/Framework \"Framework\") de la famille [xUnit](https:\/\/fr.wikipedia.org\/wiki\/XUnit \"XUnit\") permettent la génération des classes de test unitaire. Cependant ces frameworks ne fournissent que le squelette des classes. Les tests devront donc être écrits par le développeur.\n\nLa génération de tests unitaires est un sujet important pour les chercheurs et plusieurs conférences s'intéressent à cette problématique, telles que [International Symposium on Software Testing and Analysis](https:\/\/fr.wikipedia.org\/w\/index.php?title=International_Symposium_on_Software_Testing_and_Analysis&action=edit&redlink=1 \"International Symposium on Software Testing and Analysis (page inexistante)\") (ISSTA), [International Conference on Software Engineering](https:\/\/fr.wikipedia.org\/w\/index.php?title=International_Conference_on_Software_Engineering&action=edit&redlink=1 \"International Conference on Software Engineering (page inexistante)\") (ICSE) et [Automated Software Engineering](https:\/\/fr.wikipedia.org\/w\/index.php?title=Automated_Software_Engineering&action=edit&redlink=1 \"Automated Software Engineering (page inexistante)\") (ASE).\n\nLors d'une modification dans le code d'un programme, il se peut que certains tests ne passent plus ; dans ce cas, le développeur doit déterminer si cela vient du code en lui-même ou du test : si cela vient du test, le développeur doit modifier son test car la suppression de celui-ci entraînerait une augmentation des chances de régression du programme. Certains chercheurs ont développé des outils pour résoudre ce problème.\n\nReAssert[\\[14\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-14) est un outil suggérant des réparations pour un test qui échoue, il analyse les tests à modifier et suggère des changements au développeur, si cette suggestion convient au développeur, il peut effectuer le changement en cliquant sur un bouton.\n\nLes tests unitaires paramétrables sont des tests unitaires qui prennent des paramètres. Ils peuvent ensuite utiliser des outils comme QuickCheck pour générer des paramètres. Ces tests sont supportés par [JUnit](https:\/\/fr.wikipedia.org\/wiki\/JUnit \"JUnit\"), [TestNG](https:\/\/fr.wikipedia.org\/wiki\/TestNG \"TestNG\") et NUnit.\n\nEn s'appuyant sur des cas concrets d'entrée et sortie, la génération d'Oracle et sur la couverture de test pour minimiser les cas, des chercheurs ont réussi à générer des tests unitaires paramétrables[\\[15\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-15). Les résultats de cette méthode sont prometteurs.\n\nIl existe une multitude de cadriciels (*[framework](https:\/\/fr.wikipedia.org\/wiki\/Framework \"Framework\")*) permettant de réaliser facilement des tests unitaires. Il en existe dans les principaux [langages de programmation](https:\/\/fr.wikipedia.org\/wiki\/Langage_de_programmation \"Langage de programmation\"). Par exemple `Test::More`[\\[16\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-16) pour le [Perl](https:\/\/fr.wikipedia.org\/wiki\/Langage_Perl \"Langage Perl\").\n\nLe terme générique « [xUnit](https:\/\/fr.wikipedia.org\/wiki\/XUnit \"XUnit\") » désigne un outil permettant de réaliser des tests unitaires dans un langage donné (dont l'initiale remplace « x » le plus souvent).\n\n- AUnit[\\[17\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-17) pour [Ada](https:\/\/fr.wikipedia.org\/wiki\/Ada_\\(langage\\) \"Ada (langage)\") ;\n- ASUnit[\\[18\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-18) pour [ActionScript](https:\/\/fr.wikipedia.org\/wiki\/ActionScript \"ActionScript\") ;\n- Cppunit[\\[19\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-19) pour [C++](https:\/\/fr.wikipedia.org\/wiki\/C%2B%2B \"C++\") ;\n- CUnit[\\[20\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-20) pour [C](https:\/\/fr.wikipedia.org\/wiki\/C_\\(langage\\) \"C (langage)\") ;\n- DUnit pour [Delphi](https:\/\/fr.wikipedia.org\/wiki\/Embarcadero_Delphi \"Embarcadero Delphi\") ;\n- FLEXunit pour [Adobe Flex](https:\/\/fr.wikipedia.org\/wiki\/Adobe_Flex \"Adobe Flex\") ;\n- [Google](https:\/\/fr.wikipedia.org\/wiki\/Google \"Google\") Test[\\[21\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-21) et Boost Test[\\[22\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-22) pour [C++](https:\/\/fr.wikipedia.org\/wiki\/C%2B%2B \"C++\") ;\n- HUnit[\\[23\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-23) pour [Haskell](https:\/\/fr.wikipedia.org\/wiki\/Haskell \"Haskell\") ;\n- JSUnit[\\[24\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-24), QUnit[\\[25\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-25), [Unit.js](https:\/\/fr.wikipedia.org\/wiki\/Unit.js \"Unit.js\")[\\[26\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-26) et Jest[\\[27\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-27) pour [JavaScript](https:\/\/fr.wikipedia.org\/wiki\/JavaScript \"JavaScript\") ;\n- [JUnit](https:\/\/fr.wikipedia.org\/wiki\/JUnit \"JUnit\")[\\[28\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-28) et [TestNG](https:\/\/fr.wikipedia.org\/wiki\/TestNG \"TestNG\")[\\[29\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-29) pour [Java](https:\/\/fr.wikipedia.org\/wiki\/Java_\\(langage\\) \"Java (langage)\") ;\n- NUnit[\\[30\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-30) pour [.NET](https:\/\/fr.wikipedia.org\/wiki\/Microsoft_.NET \"Microsoft .NET\") ;\n- [Microsoft](https:\/\/fr.wikipedia.org\/wiki\/Microsoft \"Microsoft\") Unit Test[\\[31\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-31) pour [.NET](https:\/\/fr.wikipedia.org\/wiki\/Microsoft_.NET \"Microsoft .NET\") ;\n- xUnit[\\[32\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-32) pour [.NET](https:\/\/fr.wikipedia.org\/wiki\/Microsoft_.NET \"Microsoft .NET\") ;\n- NUnitASP[\\[33\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-33) pour [ASP.NET](https:\/\/fr.wikipedia.org\/wiki\/ASP.NET \"ASP.NET\") (support interrompu depuis le\n  31 janvier 2008\n  ) ;\n- OUnit[\\[34\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-34) pour [OCaml](https:\/\/fr.wikipedia.org\/wiki\/OCaml \"OCaml\") ;\n- OCunit pour [Objective C](https:\/\/fr.wikipedia.org\/wiki\/Objective_C \"Objective C\") ;\n- PBUnit pour [PowerBuilder](https:\/\/fr.wikipedia.org\/wiki\/PowerBuilder \"PowerBuilder\") ;\n- [PHPUnit](https:\/\/fr.wikipedia.org\/wiki\/PHPUnit \"PHPUnit\")[\\[35\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-35), SimpleTest[\\[36\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-36) et Atoum[\\[37\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-37) pour [PHP](https:\/\/fr.wikipedia.org\/wiki\/PHP \"PHP\") ;\n- plunit pour [Prolog](https:\/\/fr.wikipedia.org\/wiki\/Prolog \"Prolog\") ;\n- utPLSQL[\\[38\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-38) pour [PL\/SQL](https:\/\/fr.wikipedia.org\/wiki\/PL\/SQL \"PL\/SQL\") ;\n- Unittest et [PyUnit](https:\/\/fr.wikipedia.org\/wiki\/PyUnit \"PyUnit\") pour [Python](https:\/\/fr.wikipedia.org\/wiki\/Python_\\(langage\\) \"Python (langage)\") ;\n- [Tape](https:\/\/fr.wikipedia.org\/wiki\/Tape_\\(framework_de_tests_JavaScript\\) \"Tape (framework de tests JavaScript)\") pour [JavaScript](https:\/\/fr.wikipedia.org\/wiki\/JavaScript \"JavaScript\") ;\n- Test::Unit pour [Ruby](https:\/\/fr.wikipedia.org\/wiki\/Ruby \"Ruby\") ;\n- Test::More pour [Perl](https:\/\/fr.wikipedia.org\/wiki\/Langage_Perl \"Langage Perl\") ;\n- [Typemock](https:\/\/fr.wikipedia.org\/w\/index.php?title=Typemock&action=edit&redlink=1 \"Typemock (page inexistante)\") pour .NET, C++, C\\#. Avec Typemock vous pouvez travailler sur legacy code aussi.\n- SUnit[\\[39\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-39) pour [Smalltalk](https:\/\/fr.wikipedia.org\/wiki\/Smalltalk \"Smalltalk\") ;\n- RPGUnit[\\[40\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-40) pour RPG ;\n- ScalaTest pour Scala\n- SASUnit[\\[41\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-41) pour [SAS](https:\/\/fr.wikipedia.org\/wiki\/SAS_\\(langage\\) \"SAS (langage)\").\n\nDivers outils permettent l'automatisation des tests unitaires :\n\n- Le module TBrun de la suite d'outils [LDRA](https:\/\/fr.wikipedia.org\/wiki\/LDRA \"LDRA\") ;\n- Tessy (distribution : Hitex Development Tools\/Allemagne).\n- Ponicode, génération de tests unitaires en Javascript[\\[42\\]](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_note-42).\n\n- [Cycle en V](https:\/\/fr.wikipedia.org\/wiki\/Cycle_en_V \"Cycle en V\")\n- [Test](https:\/\/fr.wikipedia.org\/wiki\/Test_\\(informatique\\) \"Test (informatique)\")\n- [Extreme programming](https:\/\/fr.wikipedia.org\/wiki\/Extreme_programming \"Extreme programming\")\n- [Test Driven Development](https:\/\/fr.wikipedia.org\/wiki\/Test_Driven_Development \"Test Driven Development\")\n\n1. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-1)\n   (en)\n   \n   Benington, Herbert D., «\n   \n   Production of large computer programs\n   \n   », *Proceedings of the Symposium on Advanced Programming Methods for Digital Computers, Washington, D.C., June 28-29, 1956*, Office of Naval Research, Department of the Navy,‎\n   \n   1956\n   \n   ,\n   \n   p.\n   \n   15-28\n2. ↑ [a](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-:0_2-0) et [b](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-:0_2-1)\n   H. D. Benington, «\n   \n   Production of large computer programs\n   \n   », *Proceedings of the 9th international conference on Software Engineering*, IEEE Computer Society Press, iCSE '87,‎\n   \n   1er\n   \n   mars 1987\n   \n   ,\n   \n   p.\n   \n   299–310\n   \n   ([ISBN](https:\/\/fr.wikipedia.org\/wiki\/International_Standard_Book_Number \"International Standard Book Number\") [978-0-89791-216-7](https:\/\/fr.wikipedia.org\/wiki\/Sp%C3%A9cial:Ouvrages_de_r%C3%A9f%C3%A9rence\/978-0-89791-216-7 \"Spécial:Ouvrages de référence\/978-0-89791-216-7\"), [DOI](https:\/\/fr.wikipedia.org\/wiki\/Digital_Object_Identifier \"Digital Object Identifier\") [10\\.5555\/41765.41799](https:\/\/dx.doi.org\/10.5555\/41765.41799), [lire en ligne](https:\/\/dl.acm.org\/doi\/10.5555\/41765.41799), consulté le\n   \n   3 avril 2024\n   \n   )\n3. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-3)\n   Norman A. Zimmerman, «\n   \n   System integration as a programming function\n   \n   », *Proceedings of the 1969 24th national conference*, Association for Computing Machinery, aCM '69,‎\n   \n   26 août 1969\n   \n   ,\n   \n   p.\n   \n   459–467\n   \n   ([ISBN](https:\/\/fr.wikipedia.org\/wiki\/International_Standard_Book_Number \"International Standard Book Number\") [978-1-4503-7493-4](https:\/\/fr.wikipedia.org\/wiki\/Sp%C3%A9cial:Ouvrages_de_r%C3%A9f%C3%A9rence\/978-1-4503-7493-4 \"Spécial:Ouvrages de référence\/978-1-4503-7493-4\"), [DOI](https:\/\/fr.wikipedia.org\/wiki\/Digital_Object_Identifier \"Digital Object Identifier\") [10\\.1145\/800195.805951](https:\/\/dx.doi.org\/10.1145\/800195.805951), [lire en ligne](https:\/\/dl.acm.org\/doi\/10.1145\/800195.805951), consulté le\n   \n   3 avril 2024\n   \n   )\n4. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-4)\n   (en)\n   \n   Gouvernement des Etats Unis d'Amérique, Département de la Défence,\n   \n   MIL-STD-483 Military standard: configuration management practices for systems, equipment, munitions, and computer programs\n   \n   ,\n   \n   31 décembre 1970\n   \n   , Section 3.4.7.2. \"The contractor shall then code and test software Units, and enter the source and object code, and associated listings of each successfully tested Unit into the Developmental Configuration\"\n5. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-5)\n   (en)\n   \n   Michael F. Tighe, «\n   \n   The value of a proper software quality assurance methodology\n   \n   », *ACM SIGMETRICS Performance Evaluation Review*,\n   \n   vol.\n   \n   7,\n   \n   nos\n   \n   3-4,‎\n   \n   novembre 1978\n   \n   ,\n   \n   p.\n   \n   165–172\n   \n   ([ISSN](https:\/\/fr.wikipedia.org\/wiki\/International_Standard_Serial_Number \"International Standard Serial Number\") [0163-5999](https:\/\/portal.issn.org\/resource\/issn\/0163-5999), [DOI](https:\/\/fr.wikipedia.org\/wiki\/Digital_Object_Identifier \"Digital Object Identifier\") [10\\.1145\/1007775.811118](https:\/\/dx.doi.org\/10.1145\/1007775.811118), [lire en ligne](https:\/\/dl.acm.org\/doi\/10.1145\/1007775.811118), consulté le\n   \n   3 avril 2024\n   \n   )\n6. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-6) [Camp Smalltalk SUnit](http:\/\/sunit.sourceforge.net\/)\n7. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-7) *[Simple Smalltalk Testing:With Patterns](http:\/\/www.xprogramming.com\/testfram.htm)*, in *Smalltalk Report* octobre 1994, Kent Beck\n8. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-8)\n   (en)\n   \n   Ward Cunningham, «\n   \n   [Testing Framework](http:\/\/wiki.c2.com\/?TestingFramework)\n   \n   » ![Accès libre](https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/6\/65\/Lock-green.svg\/20px-Lock-green.svg.png), sur wiki.c2.com\n   \n   .\n9. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-9) [Xunit, Martin Fowler](http:\/\/www.martinfowler.com\/bliki\/Xunit.html)\n10. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-10) GNU Based Compilation System for Space Embedded Applications, Blondin, J. P. & Martignano, M., DASIA 98 - Data Systems in Aerospace, Proceedings of the conference held 25-28 May, 1998 in Athens, Greece, Edited by B. Kaldeich-Schü.rmann. ESA SP-422. Paris: European Space Agency, 1998., p.137, \"1998ESASP.422..137B\", page 138 <http:\/\/adsbit.harvard.edu\/\/full\/1998ESASP.422..137B\/0000138.000.html>\n11. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-11) [Unit Testing Best Practices, Roy Osherove](https:\/\/fr.wikipedia.org\/wiki\/Programmation_informatique \"Programmation informatique\").\n12. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-12) [Test First, bob Martin](http:\/\/blog.8thlight.com\/uncle-bob\/2013\/09\/23\/Test-first.html).\n13. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-13) Robert Martin, *When to Mock*.\n14. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-14)\n    (en)\n    \n    Brett Daniel, Danny Dig, Tihomir Gvero, Vilas Jagannath, Johnston Jiaa, Damion Mitchell, Jurand Nogiec, Shin Hwei Tan et Darko Marinov, «\n    \n    *ReAssert: a tool for repairing broken unit tests*\n    \n    », *ICSE*,‎\n    \n    2011\n    \n    ([lire en ligne](http:\/\/dl.acm.org\/citation.cfm?doid=1985793.1985978))\n    \n    .\n15. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-15)\n    (en)\n    \n    Gordon Fraser et Andreas Zeller, «\n    \n    Generating Parameterized Unit Tests\n    \n    », *ISSTA*,‎\n    \n    2011\n    \n    ([lire en ligne](http:\/\/dl.acm.org\/citation.cfm?doid=2001420.2001464))\n    \n    .\n16. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-16) [Test::More sur CPAN](https:\/\/metacpan.org\/module\/Test::More), entre autres [modules de tests](https:\/\/metacpan.org\/search?q=Test). Voir aussi les articles de l'association des *mongueurs de Perl* dans [Linux Magazine France](https:\/\/fr.wikipedia.org\/wiki\/Linux_Magazine_France \"Linux Magazine France\") disponibles sur <http:\/\/articles.mongueurs.net\/magazines>\n17. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-17) [AUnit](https:\/\/libre.adacore.com\/aunit\/main.html)\n18. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-18) [AsUnit](http:\/\/www.asunit.org\/)\n19. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-19) [CppUnit](http:\/\/cppunit.sourceforge.net\/) et en [version 2](https:\/\/launchpad.net\/cppunit2)\n20. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-20) [CUnit](http:\/\/cunit.sourceforge.net\/)\n21. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-21) [GoogleTest](https:\/\/code.google.com\/p\/googletest\/)\n22. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-22) [Boost.Test](http:\/\/www.boost.org\/doc\/libs\/release\/libs\/test\/index.html)\n23. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-23) [HUnit](http:\/\/hunit.sourceforge.net\/)\n24. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-24) [JsUnit](http:\/\/www.jsunit.net\/)\n25. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-25) [http:\/\/qunitjs.com](http:\/\/qunitjs.com\/) Unit testing for Javascript made by the jQuery Foundation\n26. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-26)\n    (en)\n    \n    [Unit JS](http:\/\/unitjs.com\/) : « Unit testing framework for Javascript ».\n27. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-27)\n    (en)\n    \n    «\n    \n    [Jest · 🃏 Delightful JavaScript Testing](https:\/\/jestjs.io\/)\n    \n    », sur jestjs.io\n    \n    (consulté le\n    \n    2 mars 2020\n    \n    )\n    \n    .\n28. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-28) [Welcome to The New JUnit.org! \\| JUnit.org](http:\/\/junit.org\/).\n29. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-29)\n    (en)\n    \n    «\n    \n    [TestNG Documentation](http:\/\/testng.org\/)\n    \n    », sur testng.org\n    \n    (consulté le\n    \n    21 mai 2024\n    \n    )\n    \n    .\n30. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-30) [NUnit - Home](http:\/\/www.nunit.org\/)\n31. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-31)\n    (en-US)\n    \n    erickson-doug, «\n    \n    [Writing Unit Tests for the .NET Framework with the Microsoft Unit Test Framework for Managed Code - Visual Studio](https:\/\/docs.microsoft.com\/fr-fr\/visualstudio\/test\/writing-unit-tests-for-the-dotnet-framework-with-the-microsoft-unit-test-framework-for-managed-code?view=vs-2015)\n    \n    », sur docs.microsoft.com\n    \n    (consulté le\n    \n    4 septembre 2018\n    \n    )\n    \n    .\n32. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-32)\n    (en)\n    \n    «\n    \n    [Home \\> xUnit.net](https:\/\/xunit.github.io\/)\n    \n    », sur xunit.github.io\n    \n    (consulté le\n    \n    4 septembre 2018\n    \n    )\n    \n    .\n33. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-33) [NUnitAsp - ASP.NET unit testing](http:\/\/nunitasp.sourceforge.net\/)\n34. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-34) [OUnit](http:\/\/ounit.forge.ocamlcore.org\/)\n35. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-35) [PHPUnit - Trac](https:\/\/www.phpunit.de\/)\n36. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-36) [SimpleTest - Unit Testing for PHP](http:\/\/www.simpletest.org\/)\n37. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-37) [Atoum](http:\/\/www.atoum.org\/)\n38. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-38) [utPLSQL](http:\/\/utplsql.sourceforge.net\/)\n39. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-39) [Simple Smalltalk Testing: With Patterns](http:\/\/www.xprogramming.com\/testfram.htm)\n40. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-40) <http:\/\/rpgunit.sourceforge.net\/>\n41. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-41)\n    (en)\n    \n    «\n    \n    [SASUnit](https:\/\/sourceforge.net\/projects\/sasunit\/)\n    \n    », sur SourceForge\n    \n    (consulté le\n    \n    24 février 2020\n    \n    )\n    \n    .\n42. [↑](https:\/\/fr.wikipedia.org\/wiki\/Test_unitaire#cite_ref-42)\n    (en)\n    \n    «\n    \n    [Ponicode - Quick and easy Javascript unit testing](https:\/\/ponicode.com\/)\n    \n    », sur ponicode.com\n    \n    (consulté le\n    \n    23 juin 2020\n    \n    )\n    \n    .\n\n| [v](https:\/\/fr.wikipedia.org\/wiki\/Mod%C3%A8le:Palette_Qualit%C3%A9_logicielle \"Modèle:Palette Qualité logicielle\") · [m](https:\/\/fr.wikipedia.org\/w\/index.php?title=Mod%C3%A8le:Palette_Qualit%C3%A9_logicielle&action=edit)Gestion de la [qualité logicielle](https:\/\/fr.wikipedia.org\/wiki\/Qualit%C3%A9_logicielle \"Qualité logicielle\") |   |\n|---|---|\n| [Indicateurs de qualité](https:\/\/fr.wikipedia.org\/wiki\/Qualit%C3%A9_logicielle#Indicateurs_de_qualit%C3%A9_logicielle \"Qualité logicielle\") ([ISO\/CEI 9126](https:\/\/fr.wikipedia.org\/wiki\/ISO\/CEI_9126 \"ISO\/CEI 9126\")) | Capacité fonctionnelle (réponse aux [exigences](https:\/\/fr.wikipedia.org\/wiki\/Exigence_\\(ing%C3%A9nierie\\) \"Exigence (ingénierie)\")) [Fiabilité](https:\/\/fr.wikipedia.org\/wiki\/Fiabilit%C3%A9 \"Fiabilité\") [Maintenabilité](https:\/\/fr.wikipedia.org\/wiki\/Maintenabilit%C3%A9 \"Maintenabilité\") [Performance](https:\/\/fr.wikipedia.org\/wiki\/Performances_\\(informatique\\) \"Performances (informatique)\") [Portabilité](https:\/\/fr.wikipedia.org\/wiki\/Portabilit%C3%A9_\\(informatique\\) \"Portabilité (informatique)\") [Utilisabilité](https:\/\/fr.wikipedia.org\/wiki\/Utilisabilit%C3%A9 \"Utilisabilité\") |\n| Compréhension et contrôle du [code source](https:\/\/fr.wikipedia.org\/wiki\/Code_source \"Code source\") |   |\n|   |   |\n| [Tests](https:\/\/fr.wikipedia.org\/wiki\/Test_\\(informatique\\) \"Test (informatique)\") | [Acceptation](https:\/\/fr.wikipedia.org\/wiki\/Test_d%27acceptation \"Test d'acceptation\") [Intégration](https:\/\/fr.wikipedia.org\/wiki\/Test_d%27int%C3%A9gration \"Test d'intégration\") [Performance](https:\/\/fr.wikipedia.org\/wiki\/Test_de_performance \"Test de performance\") [Régression](https:\/\/fr.wikipedia.org\/wiki\/Test_de_r%C3%A9gression \"Test de régression\") [Unitaire]() [Utilisateur](https:\/\/fr.wikipedia.org\/wiki\/Test_utilisateur \"Test utilisateur\") [Validation](https:\/\/fr.wikipedia.org\/wiki\/Test_de_validation \"Test de validation\") |\n| [Métriques](https:\/\/fr.wikipedia.org\/wiki\/M%C3%A9trique_\\(logiciel\\) \"Métrique (logiciel)\") | [Cohésion](https:\/\/fr.wikipedia.org\/wiki\/Coh%C3%A9sion_\\(informatique\\) \"Cohésion (informatique)\") [Couplage](https:\/\/fr.wikipedia.org\/wiki\/Couplage_\\(informatique\\) \"Couplage (informatique)\") [Couverture de code](https:\/\/fr.wikipedia.org\/wiki\/Couverture_de_code \"Couverture de code\") [Halstead](https:\/\/fr.wikipedia.org\/wiki\/M%C3%A9triques_d%27Halstead \"Métriques d'Halstead\") [Indépendance fonctionnelle](https:\/\/fr.wikipedia.org\/wiki\/Ind%C3%A9pendance_fonctionnelle \"Indépendance fonctionnelle\") [Indice de maintenabilité](https:\/\/fr.wikipedia.org\/wiki\/Indice_de_maintenabilit%C3%A9 \"Indice de maintenabilité\") [Ligne de code](https:\/\/fr.wikipedia.org\/wiki\/Ligne_de_code \"Ligne de code\") [Nombre cyclomatique](https:\/\/fr.wikipedia.org\/wiki\/Nombre_cyclomatique \"Nombre cyclomatique\") [Point de fonction](https:\/\/fr.wikipedia.org\/wiki\/Point_de_fonction \"Point de fonction\") |\n| Remaniements | [Maintenance](https:\/\/fr.wikipedia.org\/wiki\/Maintenance_du_logiciel \"Maintenance du logiciel\") [Optimisation de code](https:\/\/fr.wikipedia.org\/wiki\/Optimisation_de_code \"Optimisation de code\") [Réusinage de code](https:\/\/fr.wikipedia.org\/wiki\/R%C3%A9usinage_de_code \"Réusinage de code\") ([Règle de trois](https:\/\/fr.wikipedia.org\/wiki\/R%C3%A8gle_de_trois_\\(programmation_informatique\\) \"Règle de trois (programmation informatique)\")) |\n| Principes de [programmation](https:\/\/fr.wikipedia.org\/wiki\/Programmation_informatique \"Programmation informatique\") |   |\n|   |   |\n| [SOLID](https:\/\/fr.wikipedia.org\/wiki\/SOLID_\\(informatique\\) \"SOLID (informatique)\") | [Responsabilité unique](https:\/\/fr.wikipedia.org\/wiki\/Principe_de_responsabilit%C3%A9_unique \"Principe de responsabilité unique\") [Ouvert\/fermé](https:\/\/fr.wikipedia.org\/wiki\/Principe_ouvert\/ferm%C3%A9 \"Principe ouvert\/fermé\") [Substitution de Liskov](https:\/\/fr.wikipedia.org\/wiki\/Principe_de_substitution_de_Liskov \"Principe de substitution de Liskov\") [Ségrégation des interfaces](https:\/\/fr.wikipedia.org\/wiki\/Principe_de_s%C3%A9gr%C3%A9gation_des_interfaces \"Principe de ségrégation des interfaces\") [Inversion des dépendances](https:\/\/fr.wikipedia.org\/wiki\/Inversion_des_d%C3%A9pendances \"Inversion des dépendances\") |\n| Mauvaises pratiques |   |\n|   |   |\n| [Antipatterns](https:\/\/fr.wikipedia.org\/wiki\/Antipattern \"Antipattern\") | [Attente active](https:\/\/fr.wikipedia.org\/wiki\/Attente_active \"Attente active\") [Grosse boule de boue](https:\/\/fr.wikipedia.org\/wiki\/Grosse_boule_de_boue \"Grosse boule de boue\") [Programmation spaghetti](https:\/\/fr.wikipedia.org\/wiki\/Programmation_spaghetti \"Programmation spaghetti\") ([syndrome](https:\/\/fr.wikipedia.org\/wiki\/Syndrome_du_plat_de_spaghettis \"Syndrome du plat de spaghettis\")) [Réinventer la roue](https:\/\/fr.wikipedia.org\/wiki\/R%C3%A9inventer_la_roue \"Réinventer la roue\") |\n|   |   |\n| [Code smells](https:\/\/fr.wikipedia.org\/wiki\/Code_smell \"Code smell\") | [Duplication de code](https:\/\/fr.wikipedia.org\/wiki\/Duplication_de_code \"Duplication de code\") [God object](https:\/\/fr.wikipedia.org\/wiki\/God_object \"God object\") |\n| Voir aussi : [Génie logiciel](https:\/\/fr.wikipedia.org\/wiki\/G%C3%A9nie_logiciel \"Génie logiciel\"), [Software craftsmanship](https:\/\/fr.wikipedia.org\/wiki\/Software_craftsmanship \"Software craftsmanship\"), [Dégradation logicielle](https:\/\/fr.wikipedia.org\/wiki\/D%C3%A9gradation_logicielle \"Dégradation logicielle\") |   |\n\n- [![icône décorative](https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/0\/02\/Circle-icons-computer.svg\/40px-Circle-icons-computer.svg.png)](https:\/\/fr.wikipedia.org\/wiki\/Portail:Informatique \"Portail de l’informatique\") [Portail de l’informatique](https:\/\/fr.wikipedia.org\/wiki\/Portail:Informatique \"Portail:Informatique\")","meta_canonical":null}

3. Robots.txt Check

Query:

Response:

4. Spam/Ban Check

Query:

Response:

5. Seen Status Check

ℹ️ Skipped - page is already crawled

📄

INDEXABLE

✅

CRAWLED

1 month ago

🤖

ROBOTS ALLOWED

Page Info Filters

Filter	Status	Condition	Details
HTTP status	PASS	`download_http_code = 200`	HTTP 200
Age cutoff	PASS	`download_stamp > now() - 6 MONTH`	1.6 months ago (distributed domain, exempt)
History drop	PASS	`isNull(history_drop_reason)`	No drop reason
Spam/ban	PASS	`fh_dont_index != 1 AND ml_spam_score = 0`	ml_spam_score=0
Canonical	PASS	`meta_canonical IS NULL OR = '' OR = src_unparsed`	Not set

Page Details

Property	Value
URL	https://fr.wikipedia.org/wiki/Test_unitaire
Last Crawled	2026-02-22 10:02:21 (1 month ago)
First Indexed	2013-08-09 19:15:25 (12 years ago)
HTTP Status Code	200
Meta Title	Test unitaire — Wikipédia
Meta Description	null
Meta Canonical	null
Boilerpipe Text	Un article de Wikipédia, l'encyclopédie libre. En programmation informatique , le test unitaire (ou TU , voire UT pour Unit Testing en anglais) est une procédure permettant de vérifier le bon fonctionnement d'une partie précise d'un logiciel ou d'une portion d'un programme (appelée « unité » ou « module »). Dans les applications non critiques, l'écriture des tests unitaires a longtemps été considérée comme une tâche secondaire. Cependant, les méthodes extreme programming (XP) et test driven development (TDD) ont remis les tests unitaires, appelés « tests du programmeur », au centre de l'activité de programmation. Les tests unitaires, en tant que principe de tester séparément des parties plus élémentaires d'un logiciel complexe, remonte aux débuts de l' ingénierie logicielle . En Juin 1956, H.D. Benington présente en effet le projet SAGE au symposium sur les méthodes de programmation avancée organisé par la marine américaine . L'approche utilisée prévoyait à l'issue de la phase de codage une étape de « tests de paramètres » pour valider la conformité des sous-programmes et composants à leur spécifications, avant de procéder à un « test d'assemblage » de ces composants [ 1 ] , [ 2 ] . En 1964, une approche similaire est décrite pour les logiciels du programme Mercury : les unités individuelles développées par différentes organisations étaient soumises à des "tests unitaires" avant d'être intégrées entre elles. En 1969, les méthodologies de tests sont structurées encore davantage, avec des tests unitaires, des tests de composants, et des tests d'intégration , dans le but de valider des parties élémentaires du logiciel séparément, puis de vérifier le bon fonctionnement des assemblages progressif en blocs plus larges [ 3 ] . Des normes publiques adoptées à la fin des années 60, telles que les standards militaires MIL-STD-483 [ 4 ] et MIL-STD-490 de l'armée américaine contribuent à une large reconnaissance et adoption des tests unitaires au sein de gros projets. Les tests unitaires étaient alors interactifs [ 2 ] , ou automatisés [ 5 ] , utilisant soit des tests programmés ou des outils de capture et répétition automatisés. En 1994 Kent Beck décrit un environnement cadre de test pour le langage Smalltalk , qui deviendra SUnit [ 6 ] par la suite [ 7 ] , [ 8 ] . En 1997, Kent Beck rencontre Erich Gamma avec lequel il crée JUnit qui, par sa popularité, entraînera la création de nombreux frameworks de tests unitaires, cet ensemble se nomme xUnit [ 9 ] . À la même époque, ATTOL Unit test est développé, puis utilisé par Sextant Avionique en 1998 [ 10 ] On écrit un test pour confronter une réalisation à sa spécification . Le test définit un critère d'arrêt (état ou sorties à l'issue de l'exécution) et permet de statuer sur le succès ou sur l'échec d'une vérification. Grâce à la spécification, on est en mesure de faire correspondre un état d'entrée donné à un résultat ou à une sortie. Le test permet de vérifier que la relation d'entrée / sortie donnée par la spécification est bel et bien réalisée. La méthode XP préconise d'écrire les tests en même temps, ou même avant la fonction à tester ( Test Driven Development ). Ceci permet de définir précisément l'interface du module à développer. Les tests sont exécutés durant tout le développement, permettant de visualiser si le code fraîchement écrit correspond au besoin. Lors d'une modification d'un programme, les tests unitaires signalent les éventuelles régressions . En effet, certains tests peuvent échouer à la suite d'une modification, il faut donc soit réécrire le test pour le faire correspondre aux nouvelles attentes, soit corriger l'erreur se situant dans le code. Les tests unitaires peuvent servir de complément à l'API , il est très utile de lire les tests pour comprendre comment s'utilise une méthode. De plus, il est possible que la documentation ne soit plus à jour, mais les tests eux correspondent à la réalité de l'application. On définit généralement 4 phases dans l'exécution d'un test unitaire : Initialisation (fonction setUp ) : définition d'un environnement de test complètement reproductible (une fixture ). Exercice : le module à tester est exécuté. Vérification (utilisation de fonctions assert ) : comparaison des résultats obtenus avec un vecteur de résultat défini. Ces tests définissent le résultat du test : SUCCÈS ( SUCCESS ) ou ÉCHEC ( FAILURE ). On peut également définir d'autres résultats comme ÉVITÉ ( SKIPPED ). Désactivation (fonction tearDown ) : désinstallation des fixtures pour retrouver l'état initial du système, dans le but de ne pas polluer les tests suivants. Tous les tests doivent être indépendants et reproductibles unitairement (quand exécutés seuls). Il s'agit pour le programmeur de tester un module , indépendamment du reste du programme, ceci afin de s'assurer qu'il réponde aux spécifications fonctionnelles et qu'il fonctionne correctement en toutes circonstances. Cette vérification est considérée comme essentielle, en particulier dans les applications critiques. Elle s'accompagne couramment d'une vérification de la couverture de code (évaluation de la couverture structurelle), qui consiste à s'assurer que l'ensemble des tests conduit à exécuter l'ensemble (ou une fraction déterminée) des instructions présentes dans le code. L'ensemble des tests unitaires doit être rejoué après une modification du code afin de vérifier qu'il n'y a pas de régressions (l'apparition de nouveaux dysfonctionnements). L'emploi d'une « stratégie de test » particulière peut limiter les tests à rejouer, par exemple : une analyse d'impact des modifications, corrélée à une preuve d'indépendance des modules, permet de cibler les cas de test unitaire à rejouer. Un test doit correspondre aux spécifications de l'application, il faut donc écrire les tests en premier puis les faire passer par la suite plutôt que d'écrire le code avant et de prendre le risque d'être influencé par celui-ci lors de la rédaction des tests [ 11 ] . Bob Martin [ 12 ] , grand défenseur de la méthode TDD , propose un modèle simple pour l'écriture des tests unitaires : Écrire une fonction de test qui doit obtenir un résultat défini dans les spécifications. Ce code appelant un code qui n'existe pas encore, celui-ci doit échouer. Ceci a pour but de définir une fonction qui teste « quelque chose ». Écrire le code (le minimum de « quelque chose ») pour faire réussir le test. Une fois le test en succès, rajouter un autre test pour obtenir un résultat légèrement différent, en faisant varier les entrées par exemple. Ce nouveau test fera faillir le code principal. Modifier le code principal pour faire réussir les tests. Recommencer, en éliminant et refactorisant les éventuelles redondances dans le code des tests. On refactorise en même temps le code principal que le code des tests. Un test unitaire doit tester une caractéristique et une seule. On ne définit pas un « scénario » de test complexe dans un test unitaire. Il est déconseillé de tester les détails d'implémentation telles que les fonctions privées d'une classe, on se concentrera à tester les fonctions publiques, c'est-à-dire les interfaces avec lesquelles les acteurs extérieurs interagissent. Ainsi, on découple les tests de l'implémentation et on se concentre sur la vérification du comportement attendu tout en gardant une flexibilité sur la manière d'arriver au résultat souhaité. Les mocks sont des objets permettant de simuler un objet réel de façon contrôlée. Dans certains cas, l'utilisation de mock est primordiale, pour un gain de temps de couverture de code , et de fiabilité des tests [ 13 ] pour simuler une base de données , un service web , etc., les interactions entre l'application et ces outils prennent du temps, l'utilisation de mock pour simuler leurs fonctionnements peut être un gain de temps considérable ; certains cas d'erreurs sont très difficile à reproduire, l'utilisation de mock permet ici de simuler une erreur pour pouvoir traiter ce cas et donc améliorer la couverture de code, par exemple le catch d'une exception ; sans l'utilisation de mock, le test peut retourner une erreur ne provenant pas du code qui est testé (par exemple une base de données). Cependant, une utilisation abusive de mock peut avoir l'effet inverse, notamment allonger le temps d'exécution des tests, rendre les tests compliqués à comprendre et à maintenir. La plupart des frameworks de la famille xUnit permettent la génération des classes de test unitaire. Cependant ces frameworks ne fournissent que le squelette des classes. Les tests devront donc être écrits par le développeur. La génération de tests unitaires est un sujet important pour les chercheurs et plusieurs conférences s'intéressent à cette problématique, telles que International Symposium on Software Testing and Analysis (ISSTA), International Conference on Software Engineering (ICSE) et Automated Software Engineering (ASE). Lors d'une modification dans le code d'un programme, il se peut que certains tests ne passent plus ; dans ce cas, le développeur doit déterminer si cela vient du code en lui-même ou du test : si cela vient du test, le développeur doit modifier son test car la suppression de celui-ci entraînerait une augmentation des chances de régression du programme. Certains chercheurs ont développé des outils pour résoudre ce problème. ReAssert [ 14 ] est un outil suggérant des réparations pour un test qui échoue, il analyse les tests à modifier et suggère des changements au développeur, si cette suggestion convient au développeur, il peut effectuer le changement en cliquant sur un bouton. Les tests unitaires paramétrables sont des tests unitaires qui prennent des paramètres. Ils peuvent ensuite utiliser des outils comme QuickCheck pour générer des paramètres. Ces tests sont supportés par JUnit , TestNG et NUnit. En s'appuyant sur des cas concrets d'entrée et sortie, la génération d'Oracle et sur la couverture de test pour minimiser les cas, des chercheurs ont réussi à générer des tests unitaires paramétrables [ 15 ] . Les résultats de cette méthode sont prometteurs. Il existe une multitude de cadriciels ( framework ) permettant de réaliser facilement des tests unitaires. Il en existe dans les principaux langages de programmation . Par exemple Test::More [ 16 ] pour le Perl . Le terme générique « xUnit » désigne un outil permettant de réaliser des tests unitaires dans un langage donné (dont l'initiale remplace « x » le plus souvent). AUnit [ 17 ] pour Ada ; ASUnit [ 18 ] pour ActionScript ; Cppunit [ 19 ] pour C++ ; CUnit [ 20 ] pour C ; DUnit pour Delphi ; FLEXunit pour Adobe Flex ; Google Test [ 21 ] et Boost Test [ 22 ] pour C++ ; HUnit [ 23 ] pour Haskell ; JSUnit [ 24 ] , QUnit [ 25 ] , Unit.js [ 26 ] et Jest [ 27 ] pour JavaScript ; JUnit [ 28 ] et TestNG [ 29 ] pour Java ; NUnit [ 30 ] pour .NET ; Microsoft Unit Test [ 31 ] pour .NET ; xUnit [ 32 ] pour .NET ; NUnitASP [ 33 ] pour ASP.NET (support interrompu depuis le 31 janvier 2008 ) ; OUnit [ 34 ] pour OCaml ; OCunit pour Objective C ; PBUnit pour PowerBuilder ; PHPUnit [ 35 ] , SimpleTest [ 36 ] et Atoum [ 37 ] pour PHP ; plunit pour Prolog ; utPLSQL [ 38 ] pour PL/SQL ; Unittest et PyUnit pour Python ; Tape pour JavaScript ; Test::Unit pour Ruby ; Test::More pour Perl ; Typemock pour .NET, C++, C#. Avec Typemock vous pouvez travailler sur legacy code aussi. SUnit [ 39 ] pour Smalltalk ; RPGUnit [ 40 ] pour RPG ; ScalaTest pour Scala SASUnit [ 41 ] pour SAS . Divers outils permettent l'automatisation des tests unitaires : Le module TBrun de la suite d'outils LDRA ; Tessy (distribution : Hitex Development Tools /Allemagne). Ponicode, génération de tests unitaires en Javascript [ 42 ] . Cycle en V Test Extreme programming Test Driven Development ↑ (en) Benington, Herbert D., « Production of large computer programs », Proceedings of the Symposium on Advanced Programming Methods for Digital Computers, Washington, D.C., June 28-29, 1956 , Office of Naval Research, Department of the Navy,‎ 1956 , p. 15-28 ↑ a et b H. D. Benington , « Production of large computer programs », Proceedings of the 9th international conference on Software Engineering , IEEE Computer Society Press, iCSE '87,‎ 1 er mars 1987 , p. 299–310 ( ISBN 978-0-89791-216-7 , DOI 10.5555/41765.41799 , lire en ligne , consulté le 3 avril 2024 ) ↑ Norman A. Zimmerman , « System integration as a programming function », Proceedings of the 1969 24th national conference , Association for Computing Machinery, aCM '69,‎ 26 août 1969 , p. 459–467 ( ISBN 978-1-4503-7493-4 , DOI 10.1145/800195.805951 , lire en ligne , consulté le 3 avril 2024 ) ↑ (en) Gouvernement des Etats Unis d'Amérique, Département de la Défence, MIL-STD-483 Military standard: configuration management practices for systems, equipment, munitions, and computer programs , 31 décembre 1970 , Section 3.4.7.2. "The contractor shall then code and test software Units, and enter the source and object code, and associated listings of each successfully tested Unit into the Developmental Configuration" ↑ (en) Michael F. Tighe , « The value of a proper software quality assurance methodology », ACM SIGMETRICS Performance Evaluation Review , vol. 7, n os 3-4,‎ novembre 1978 , p. 165–172 ( ISSN 0163-5999 , DOI 10.1145/1007775.811118 , lire en ligne , consulté le 3 avril 2024 ) ↑ Camp Smalltalk SUnit ↑ Simple Smalltalk Testing:With Patterns , in Smalltalk Report octobre 1994, Kent Beck ↑ (en) Ward Cunningham, « Testing Framework » , sur wiki.c2.com . ↑ Xunit, Martin Fowler ↑ GNU Based Compilation System for Space Embedded Applications, Blondin, J. P. & Martignano, M., DASIA 98 - Data Systems in Aerospace, Proceedings of the conference held 25-28 May, 1998 in Athens, Greece, Edited by B. Kaldeich-Schü.rmann. ESA SP-422. Paris: European Space Agency, 1998., p.137, "1998ESASP.422..137B", page 138 http://adsbit.harvard.edu//full/1998ESASP.422..137B/0000138.000.html ↑ Unit Testing Best Practices, Roy Osherove . ↑ Test First, bob Martin . ↑ Robert Martin, When to Mock . ↑ (en) Brett Daniel, Danny Dig, Tihomir Gvero, Vilas Jagannath, Johnston Jiaa, Damion Mitchell, Jurand Nogiec, Shin Hwei Tan et Darko Marinov, « ReAssert: a tool for repairing broken unit tests », ICSE ,‎ 2011 ( lire en ligne ) . ↑ (en) Gordon Fraser et Andreas Zeller, « Generating Parameterized Unit Tests », ISSTA ,‎ 2011 ( lire en ligne ) . ↑ Test::More sur CPAN , entre autres modules de tests . Voir aussi les articles de l'association des mongueurs de Perl dans Linux Magazine France disponibles sur http://articles.mongueurs.net/magazines ↑ AUnit ↑ AsUnit ↑ CppUnit et en version 2 ↑ CUnit ↑ GoogleTest ↑ Boost.Test ↑ HUnit ↑ JsUnit ↑ http://qunitjs.com Unit testing for Javascript made by the jQuery Foundation ↑ (en) Unit JS : « Unit testing framework for Javascript ». ↑ (en) « Jest · 🃏 Delightful JavaScript Testing », sur jestjs.io (consulté le 2 mars 2020 ) . ↑ Welcome to The New JUnit.org! \| JUnit.org . ↑ (en) « TestNG Documentation », sur testng.org (consulté le 21 mai 2024 ) . ↑ NUnit - Home ↑ (en-US) erickson-doug , « Writing Unit Tests for the .NET Framework with the Microsoft Unit Test Framework for Managed Code - Visual Studio », sur docs.microsoft.com (consulté le 4 septembre 2018 ) . ↑ (en) « Home > xUnit.net », sur xunit.github.io (consulté le 4 septembre 2018 ) . ↑ NUnitAsp - ASP.NET unit testing ↑ OUnit ↑ PHPUnit - Trac ↑ SimpleTest - Unit Testing for PHP ↑ Atoum ↑ utPLSQL ↑ Simple Smalltalk Testing: With Patterns ↑ http://rpgunit.sourceforge.net/ ↑ (en) « SASUnit », sur SourceForge (consulté le 24 février 2020 ) . ↑ (en) « Ponicode - Quick and easy Javascript unit testing », sur ponicode.com (consulté le 23 juin 2020 ) . v · m Gestion de la qualité logicielle Indicateurs de qualité ( ISO/CEI 9126 ) Capacité fonctionnelle (réponse aux exigences ) Fiabilité Maintenabilité Performance Portabilité Utilisabilité Compréhension et contrôle du code source Automatisation de test Commentaires Documentation Inspection de produit Programmation en binôme ou en groupe Règles de codage Revue de code Tests Acceptation Intégration Performance Régression Unitaire Utilisateur Validation Métriques Cohésion Couplage Couverture de code Halstead Indépendance fonctionnelle Indice de maintenabilité Ligne de code Nombre cyclomatique Point de fonction Remaniements Maintenance Optimisation de code Réusinage de code ( Règle de trois ) Principes de programmation Encapsulation GRASP KISS Loi de Déméter Masquage de l'information Ne vous répétez pas (DRY) Patron de conception Séparation des préoccupations YAGNI SOLID Responsabilité unique Ouvert/fermé Substitution de Liskov Ségrégation des interfaces Inversion des dépendances Mauvaises pratiques Antipatterns Attente active Grosse boule de boue Programmation spaghetti ( syndrome ) Réinventer la roue Code smells Duplication de code God object Voir aussi : Génie logiciel , Software craftsmanship , Dégradation logicielle Portail de l’informatique
Markdown	[Aller au contenu](https://fr.wikipedia.org/wiki/Test_unitaire#bodyContent) Menu principal Menu principal déplacer vers la barre latérale masquer Navigation - [Page d’accueil](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal "Accueil général [z]") - [Portails thématiques](https://fr.wikipedia.org/wiki/Portail:Accueil "Regroupements d'articles par thématiques") - [Article au hasard](https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Page_au_hasard "Affiche un article au hasard [x]") - [Contact](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Contact "Qui contacter") Contribuer - [Débuter sur Wikipédia](https://fr.wikipedia.org/wiki/Aide:D%C3%A9buter "Guide pour apprendre à contribuer à Wikipédia") - [Aide](https://fr.wikipedia.org/wiki/Aide:Accueil "Accès à l’aide") - [Communauté](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_de_la_communaut%C3%A9 "À propos du projet, ce que vous pouvez faire, où trouver les informations") - [Pages spéciales](https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Pages_sp%C3%A9ciales "Outils pour contribuer à Wikipédia [q]") - [Modifications récentes](https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Modifications_r%C3%A9centes "Liste des modifications récentes sur le wiki [r]") [![](https://fr.wikipedia.org/static/images/icons/wikipedia.png) ![Wikipédia](https://fr.wikipedia.org/static/images/mobile/copyright/wikipedia-wordmark-fr.svg) ![l'encyclopédie libre](https://fr.wikipedia.org/static/images/mobile/copyright/wikipedia-tagline-fr.svg)](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal) [Rechercher](https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Recherche "Rechercher sur Wikipédia [f]") Apparence - [Faire un don](https://donate.wikimedia.org/?wmf_source=donate&wmf_medium=sidebar&wmf_campaign=fr.wikipedia.org&uselang=fr) - [Créer un compte](https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Cr%C3%A9er_un_compte&returnto=Test+unitaire "Nous vous encourageons à créer un compte utilisateur et vous connecter ; ce n’est cependant pas obligatoire.") - [Se connecter](https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Connexion&returnto=Test+unitaire "Nous vous encourageons à vous connecter ; ce n’est cependant pas obligatoire. [o]") Outils personnels - [Faire un don](https://donate.wikimedia.org/?wmf_source=donate&wmf_medium=sidebar&wmf_campaign=fr.wikipedia.org&uselang=fr) - [Créer un compte](https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Cr%C3%A9er_un_compte&returnto=Test+unitaire "Nous vous encourageons à créer un compte utilisateur et vous connecter ; ce n’est cependant pas obligatoire.") - [Se connecter](https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Connexion&returnto=Test+unitaire "Nous vous encourageons à vous connecter ; ce n’est cependant pas obligatoire. [o]") ## Sommaire déplacer vers la barre latérale masquer - [Début](https://fr.wikipedia.org/wiki/Test_unitaire) - [1 Origine et histoire](https://fr.wikipedia.org/wiki/Test_unitaire#Origine_et_histoire) - [2 Utilité](https://fr.wikipedia.org/wiki/Test_unitaire#Utilit%C3%A9) Afficher / masquer la sous-section Utilité - [2\.1 Trouver les erreurs rapidement](https://fr.wikipedia.org/wiki/Test_unitaire#Trouver_les_erreurs_rapidement) - [2\.2 Sécuriser la maintenance](https://fr.wikipedia.org/wiki/Test_unitaire#S%C3%A9curiser_la_maintenance) - [2\.3 Documenter le code](https://fr.wikipedia.org/wiki/Test_unitaire#Documenter_le_code) - [3 Fonctionnement](https://fr.wikipedia.org/wiki/Test_unitaire#Fonctionnement) - [4 Utilisation](https://fr.wikipedia.org/wiki/Test_unitaire#Utilisation) Afficher / masquer la sous-section Utilisation - [4\.1 Commencer par les tests](https://fr.wikipedia.org/wiki/Test_unitaire#Commencer_par_les_tests) - [4\.2 Utiliser des mocks](https://fr.wikipedia.org/wiki/Test_unitaire#Utiliser_des_mocks) - [5 Génération](https://fr.wikipedia.org/wiki/Test_unitaire#G%C3%A9n%C3%A9ration) Afficher / masquer la sous-section Génération - [5\.1 Correction de test unitaire](https://fr.wikipedia.org/wiki/Test_unitaire#Correction_de_test_unitaire) - [5\.2 Test unitaire paramétrable](https://fr.wikipedia.org/wiki/Test_unitaire#Test_unitaire_param%C3%A9trable) - [6 Environnements de développement](https://fr.wikipedia.org/wiki/Test_unitaire#Environnements_de_d%C3%A9veloppement) Afficher / masquer la sous-section Environnements de développement - [6\.1 Frameworks xUnit](https://fr.wikipedia.org/wiki/Test_unitaire#Frameworks_xUnit) - [7 Outils commerciaux](https://fr.wikipedia.org/wiki/Test_unitaire#Outils_commerciaux) - [8 Articles connexes](https://fr.wikipedia.org/wiki/Test_unitaire#Articles_connexes) - [9 Notes](https://fr.wikipedia.org/wiki/Test_unitaire#Notes) Basculer la table des matières # Test unitaire 29 langues - [العربية](https://ar.wikipedia.org/wiki/%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1_%D8%A7%D9%84%D9%88%D8%AD%D8%AF%D8%A9 "اختبار الوحدة – arabe") - [Български](https://bg.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%BD%D0%BE_%D1%82%D0%B5%D1%81%D1%82%D0%B2%D0%B0%D0%BD%D0%B5 "Компонентно тестване – bulgare") - [Català](https://ca.wikipedia.org/wiki/Proves_unit%C3%A0ries "Proves unitàries – catalan") - [Čeština](https://cs.wikipedia.org/wiki/Unit_testing "Unit testing – tchèque") - [Dansk](https://da.wikipedia.org/wiki/Unit_test "Unit test – danois") - [Deutsch](https://de.wikipedia.org/wiki/Modultest "Modultest – allemand") - [English](https://en.wikipedia.org/wiki/Unit_testing "Unit testing – anglais") - [Español](https://es.wikipedia.org/wiki/Prueba_unitaria "Prueba unitaria – espagnol") - [Eesti](https://et.wikipedia.org/wiki/%C3%9Chiktestimine "Ühiktestimine – estonien") - [فارسی](https://fa.wikipedia.org/wiki/%D8%A2%D8%B2%D9%85%D9%88%D9%86_%D9%88%D8%A7%D8%AD%D8%AF "آزمون واحد – persan") - [Suomi](https://fi.wikipedia.org/wiki/Yksikk%C3%B6testaaminen "Yksikkötestaaminen – finnois") - [עברית](https://he.wikipedia.org/wiki/%D7%91%D7%93%D7%99%D7%A7%D7%95%D7%AA_%D7%99%D7%97%D7%99%D7%93%D7%94 "בדיקות יחידה – hébreu") - [Magyar](https://hu.wikipedia.org/wiki/Egys%C3%A9gtesztel%C3%A9s "Egységtesztelés – hongrois") - [Interlingua](https://ia.wikipedia.org/wiki/Proba_unitari "Proba unitari – interlingua") - [Bahasa Indonesia](https://id.wikipedia.org/wiki/Pengujian_unit "Pengujian unit – indonésien") - [Italiano](https://it.wikipedia.org/wiki/Unit_testing "Unit testing – italien") - [日本語](https://ja.wikipedia.org/wiki/%E5%8D%98%E4%BD%93%E3%83%86%E3%82%B9%E3%83%88 "単体テスト – japonais") - [한국어](https://ko.wikipedia.org/wiki/%EC%9C%A0%EB%8B%9B_%ED%85%8C%EC%8A%A4%ED%8A%B8 "유닛 테스트 – coréen") - [Nederlands](https://nl.wikipedia.org/wiki/Unittesten "Unittesten – néerlandais") - [Norsk bokmål](https://no.wikipedia.org/wiki/Enhetstesting "Enhetstesting – norvégien bokmål") - [Polski](https://pl.wikipedia.org/wiki/Test_jednostkowy "Test jednostkowy – polonais") - [Português](https://pt.wikipedia.org/wiki/Teste_de_unidade "Teste de unidade – portugais") - [Русский](https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D1%83%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5 "Модульное тестирование – russe") - [Српски / srpski](https://sr.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D1%83%D0%BB%D0%B0%D1%80%D0%BD%D0%BE_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%B0%D1%9A%D0%B5 "Модуларно тестирање – serbe") - [தமிழ்](https://ta.wikipedia.org/wiki/%E0%AE%93%E0%AE%B0%E0%AE%B2%E0%AE%95%E0%AF%81%E0%AE%9A%E0%AF%8D_%E0%AE%9A%E0%AF%8B%E0%AE%A4%E0%AE%A9%E0%AF%88 "ஓரலகுச் சோதனை – tamoul") - [Türkçe](https://tr.wikipedia.org/wiki/Birim_testi "Birim testi – turc") - [Українська](https://uk.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D1%83%D0%BB%D1%8C%D0%BD%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F "Модульне тестування – ukrainien") - [Tiếng Việt](https://vi.wikipedia.org/wiki/Unit_testing "Unit testing – vietnamien") - [中文](https://zh.wikipedia.org/wiki/%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95 "单元测试 – chinois") [Modifier les liens](https://www.wikidata.org/wiki/Special:EntityPage/Q907375#sitelinks-wikipedia "Modifier les liens interlangues") - [Article](https://fr.wikipedia.org/wiki/Test_unitaire "Voir le contenu de la page [c]") - [Discussion](https://fr.wikipedia.org/wiki/Discussion:Test_unitaire "Discussion au sujet de cette page de contenu [t]") français - [Lire](https://fr.wikipedia.org/wiki/Test_unitaire) - [Modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit "Modifier cette page [v]") - [Modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit "Modifier le wikicode de cette page [e]") - [Voir l’historique](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=history "Historique des versions de cette page [h]") Outils Outils déplacer vers la barre latérale masquer Actions - [Lire](https://fr.wikipedia.org/wiki/Test_unitaire) - [Modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit "Modifier cette page [v]") - [Modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit "Modifier le wikicode de cette page [e]") - [Voir l’historique](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=history) Général - [Pages liées](https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Pages_li%C3%A9es/Test_unitaire "Liste des pages liées qui pointent sur celle-ci [j]") - [Suivi des pages liées](https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Suivi_des_liens/Test_unitaire "Liste des modifications récentes des pages appelées par celle-ci [k]") - [Téléverser un fichier](https://fr.wikipedia.org/wiki/Aide:Importer_un_fichier "Téléverser des fichiers [u]") - [Lien permanent](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&oldid=233485497 "Adresse permanente de cette version de cette page") - [Informations sur la page](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=info "Davantage d’informations sur cette page") - [Citer cette page](https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Citer&page=Test_unitaire&id=233485497&wpFormIdentifier=titleform "Informations sur la manière de citer cette page") - [Obtenir l'URL raccourcie](https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:UrlShortener&url=https%3A%2F%2Ffr.wikipedia.org%2Fwiki%2FTest_unitaire) - [Télécharger le code QR](https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:QrCode&url=https%3A%2F%2Ffr.wikipedia.org%2Fwiki%2FTest_unitaire) Imprimer / exporter - [Créer un livre](https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Livre&bookcmd=book_creator&referer=Test+unitaire) - [Télécharger comme PDF](https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:DownloadAsPdf&page=Test_unitaire&action=show-download-screen) - [Version imprimable](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&printable=yes "Version imprimable de cette page [p]") Dans d’autres projets - [Wikilivres](https://fr.wikibooks.org/wiki/Introduction_au_test_logiciel/Tests_unitaires) - [Élément Wikidata](https://www.wikidata.org/wiki/Special:EntityPage/Q907375 "Lien vers l’élément dans le dépôt de données connecté [g]") Apparence déplacer vers la barre latérale masquer Un article de Wikipédia, l'encyclopédie libre. [![Page d’aide sur l’homonymie](https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Logo_disambig.svg/20px-Logo_disambig.svg.png)](https://fr.wikipedia.org/wiki/Aide:Homonymie "Aide:Homonymie") Pour les articles homonymes, voir [Test](https://fr.wikipedia.org/wiki/Test "Test"). En [programmation informatique](https://fr.wikipedia.org/wiki/Programmation_informatique "Programmation informatique"), le test unitaire (ou TU, voire *UT* pour Unit Testing en anglais) est une procédure permettant de vérifier le bon fonctionnement d'une partie précise d'un [logiciel](https://fr.wikipedia.org/wiki/Logiciel "Logiciel") ou d'une portion d'un [programme](https://fr.wikipedia.org/wiki/Programme_informatique "Programme informatique") (appelée « unité » ou « module »). Dans les applications non critiques, l'écriture des tests unitaires a longtemps été considérée comme une tâche secondaire. Cependant, les méthodes [extreme programming](https://fr.wikipedia.org/wiki/Extreme_programming "Extreme programming") (XP) et [test driven development](https://fr.wikipedia.org/wiki/Test_driven_development "Test driven development") (TDD) ont remis les tests unitaires, appelés « tests du programmeur », au centre de l'activité de programmation. ## Origine et histoire \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=1 "Modifier la section : Origine et histoire") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=1 "Modifier le code source de la section : Origine et histoire")\] Les tests unitaires, en tant que principe de tester séparément des parties plus élémentaires d'un logiciel complexe, remonte aux débuts de l'[ingénierie logicielle](https://fr.wikipedia.org/wiki/Ing%C3%A9nierie_logicielle "Ingénierie logicielle"). En Juin 1956, H.D. Benington présente en effet le projet [SAGE](https://fr.wikipedia.org/wiki/Semi-Automatic_Ground_Environment "Semi-Automatic Ground Environment") au symposium sur les méthodes de programmation avancée organisé par la [marine américaine](https://fr.wikipedia.org/wiki/United_States_Navy "United States Navy"). L'approche utilisée prévoyait à l'issue de la phase de codage une étape de « tests de paramètres » pour valider la conformité des sous-programmes et composants à leur spécifications, avant de procéder à un « test d'assemblage » de ces composants[\[1\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-1),[\[2\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-:0-2). En 1964, une approche similaire est décrite pour les logiciels du [programme Mercury](https://fr.wikipedia.org/wiki/Programme_Mercury "Programme Mercury") : les unités individuelles développées par différentes organisations étaient soumises à des "tests unitaires" avant d'être intégrées entre elles. En 1969, les méthodologies de tests sont structurées encore davantage, avec des tests unitaires, des tests de composants, et des [tests d'intégration](https://fr.wikipedia.org/wiki/Test_d%27int%C3%A9gration "Test d'intégration"), dans le but de valider des parties élémentaires du logiciel séparément, puis de vérifier le bon fonctionnement des assemblages progressif en blocs plus larges[\[3\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-3). Des normes publiques adoptées à la fin des années 60, telles que les standards militaires MIL-STD-483[\[4\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-4) et MIL-STD-490 de l'armée américaine contribuent à une large reconnaissance et adoption des tests unitaires au sein de gros projets. Les tests unitaires étaient alors interactifs[\[2\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-:0-2), ou automatisés[\[5\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-5), utilisant soit des tests programmés ou des outils de capture et répétition automatisés. En 1994 [Kent Beck](https://fr.wikipedia.org/wiki/Kent_Beck "Kent Beck") décrit un environnement cadre de test pour le langage [Smalltalk](https://fr.wikipedia.org/wiki/Smalltalk "Smalltalk"), qui deviendra [SUnit](https://fr.wikipedia.org/w/index.php?title=SUnit&action=edit&redlink=1 "SUnit (page inexistante)")[\[6\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-6) par la suite[\[7\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-7),[\[8\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-8). En 1997, [Kent Beck](https://fr.wikipedia.org/wiki/Kent_Beck "Kent Beck") rencontre [Erich Gamma](https://fr.wikipedia.org/wiki/Erich_Gamma "Erich Gamma") avec lequel il crée [JUnit](https://fr.wikipedia.org/wiki/JUnit "JUnit") qui, par sa popularité, entraînera la création de nombreux [frameworks](https://fr.wikipedia.org/wiki/Frameworks "Frameworks") de tests unitaires, cet ensemble se nomme [xUnit](https://fr.wikipedia.org/wiki/XUnit "XUnit")[\[9\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-9). À la même époque, ATTOL Unit test est développé, puis utilisé par [Sextant Avionique](https://fr.wikipedia.org/wiki/Sextant_Avionique "Sextant Avionique") en 1998[\[10\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-10) ## Utilité \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=2 "Modifier la section : Utilité") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=2 "Modifier le code source de la section : Utilité")\] On écrit un test pour confronter une réalisation à sa [spécification](https://fr.wikipedia.org/wiki/Sp%C3%A9cification_fonctionnelle "Spécification fonctionnelle"). Le [test](https://fr.wikipedia.org/wiki/Test_\(informatique\) "Test (informatique)") définit un critère d'arrêt (état ou sorties à l'issue de l'exécution) et permet de statuer sur le succès ou sur l'échec d'une vérification. Grâce à la spécification, on est en mesure de faire correspondre un état d'entrée donné à un résultat ou à une sortie. Le [test](https://fr.wikipedia.org/wiki/Test_\(informatique\) "Test (informatique)") permet de vérifier que la relation d'entrée / sortie donnée par la spécification est bel et bien réalisée. ### Trouver les erreurs rapidement \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=3 "Modifier la section : Trouver les erreurs rapidement") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=3 "Modifier le code source de la section : Trouver les erreurs rapidement")\] La méthode XP préconise d'écrire les tests en même temps, ou même avant la fonction à tester ([Test Driven Development](https://fr.wikipedia.org/wiki/Test_Driven_Development "Test Driven Development")). Ceci permet de définir précisément l'interface du module à développer. Les tests sont exécutés durant tout le développement, permettant de visualiser si le code fraîchement écrit correspond au besoin. ### Sécuriser la maintenance \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=4 "Modifier la section : Sécuriser la maintenance") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=4 "Modifier le code source de la section : Sécuriser la maintenance")\] Lors d'une modification d'un programme, les tests unitaires signalent les éventuelles [régressions](https://fr.wikipedia.org/wiki/Test_de_r%C3%A9gression "Test de régression"). En effet, certains tests peuvent échouer à la suite d'une modification, il faut donc soit réécrire le test pour le faire correspondre aux nouvelles attentes, soit corriger l'erreur se situant dans le code. ### Documenter le code \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=5 "Modifier la section : Documenter le code") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=5 "Modifier le code source de la section : Documenter le code")\] Les tests unitaires peuvent servir de complément à [l'API](https://fr.wikipedia.org/wiki/Interface_de_programmation "Interface de programmation"), il est très utile de lire les tests pour comprendre comment s'utilise une méthode. De plus, il est possible que la documentation ne soit plus à jour, mais les tests eux correspondent à la réalité de l'application. ## Fonctionnement \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=6 "Modifier la section : Fonctionnement") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=6 "Modifier le code source de la section : Fonctionnement")\] On définit généralement 4 phases dans l'exécution d'un test unitaire : 1. Initialisation (fonction `setUp`) : définition d'un environnement de test complètement reproductible (une [fixture](https://fr.wikipedia.org/wiki/Test_fixture "Test fixture")). 2. Exercice : le module à tester est exécuté. 3. Vérification (utilisation de fonctions `assert`) : comparaison des résultats obtenus avec un vecteur de résultat défini. Ces tests définissent le résultat du test : SUCCÈS (`SUCCESS`) ou ÉCHEC (`FAILURE`). On peut également définir d'autres résultats comme ÉVITÉ (`SKIPPED`). 4. Désactivation (fonction `tearDown`) : désinstallation des [fixtures](https://fr.wikipedia.org/wiki/Test_fixture "Test fixture") pour retrouver l'état initial du système, dans le but de ne pas polluer les tests suivants. Tous les tests doivent être indépendants et reproductibles unitairement (quand exécutés seuls). ## Utilisation \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=7 "Modifier la section : Utilisation") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=7 "Modifier le code source de la section : Utilisation")\] Il s'agit pour le programmeur de tester un [module](https://fr.wikipedia.org/wiki/Module_\(programmation\) "Module (programmation)"), indépendamment du reste du programme, ceci afin de s'assurer qu'il réponde aux [spécifications fonctionnelles](https://fr.wikipedia.org/wiki/Sp%C3%A9cification_\(informatique\) "Spécification (informatique)") et qu'il fonctionne correctement en toutes circonstances. Cette vérification est considérée comme essentielle, en particulier dans les applications critiques. Elle s'accompagne couramment d'une vérification de la [couverture de code](https://fr.wikipedia.org/wiki/Couverture_de_code "Couverture de code") (évaluation de la couverture structurelle), qui consiste à s'assurer que l'ensemble des [tests](https://fr.wikipedia.org/wiki/Test_\(informatique\) "Test (informatique)") conduit à exécuter l'ensemble (ou une fraction déterminée) des instructions présentes dans le code. L'ensemble des tests unitaires doit être rejoué après une modification du code afin de vérifier qu'il n'y a pas de [régressions](https://fr.wikipedia.org/wiki/Non-r%C3%A9gression "Non-régression") (l'apparition de nouveaux dysfonctionnements). L'emploi d'une « stratégie de test » particulière peut limiter les tests à rejouer, par exemple : une analyse d'impact des modifications, corrélée à une preuve d'indépendance des modules, permet de cibler les cas de test unitaire à rejouer. ### Commencer par les tests \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=8 "Modifier la section : Commencer par les tests") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=8 "Modifier le code source de la section : Commencer par les tests")\] Un test doit correspondre aux spécifications de l'application, il faut donc écrire les tests en premier puis les faire passer par la suite plutôt que d'écrire le code avant et de prendre le risque d'être influencé par celui-ci lors de la rédaction des tests[\[11\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-11). Bob Martin[\[12\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-12), grand défenseur de la méthode [TDD](https://fr.wikipedia.org/wiki/Test_Driven_Development "Test Driven Development"), propose un [modèle](https://fr.wikipedia.org/wiki/Pattern "Pattern") simple pour l'écriture des tests unitaires : 1. Écrire une fonction de test qui doit obtenir un résultat défini dans les spécifications. Ce code appelant un code qui n'existe pas encore, celui-ci doit échouer. Ceci a pour but de définir une fonction qui teste « quelque chose ». 2. Écrire le code (le minimum de « quelque chose ») pour faire réussir le test. 3. Une fois le test en succès, rajouter un autre test pour obtenir un résultat légèrement différent, en faisant varier les entrées par exemple. Ce nouveau test fera faillir le code principal. 4. Modifier le code principal pour faire réussir les tests. 5. Recommencer, en éliminant et [refactorisant](https://fr.wikipedia.org/wiki/R%C3%A9usinage_de_code "Réusinage de code") les éventuelles redondances dans le code des tests. On refactorise en même temps le code principal que le code des tests. 6. Un test unitaire doit tester une caractéristique et une seule. On ne définit pas un « [scénario](https://fr.wikipedia.org/wiki/Sc%C3%A9nario_\(informatique\) "Scénario (informatique)") » de test complexe dans un test unitaire. 7. Il est déconseillé de tester les détails d'implémentation telles que les fonctions privées d'une classe, on se concentrera à tester les fonctions publiques, c'est-à-dire les interfaces avec lesquelles les acteurs extérieurs interagissent. Ainsi, on découple les tests de l'implémentation et on se concentre sur la vérification du comportement attendu tout en gardant une flexibilité sur la manière d'arriver au résultat souhaité. ### Utiliser des mocks \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=9 "Modifier la section : Utiliser des mocks") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=9 "Modifier le code source de la section : Utiliser des mocks")\] Les [mocks](https://fr.wikipedia.org/wiki/Mock_\(programmation_orient%C3%A9e_objet\) "Mock (programmation orientée objet)") sont des objets permettant de simuler un objet réel de façon contrôlée. Dans certains cas, l'utilisation de mock est primordiale, pour un gain de temps de [couverture de code](https://fr.wikipedia.org/wiki/Couverture_de_code "Couverture de code"), et de fiabilité des tests[\[13\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-13) - pour simuler une [base de données](https://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es "Base de données"), un [service web](https://fr.wikipedia.org/wiki/Service_web "Service web"), etc., les interactions entre l'application et ces outils prennent du temps, l'utilisation de mock pour simuler leurs fonctionnements peut être un gain de temps considérable ; - certains cas d'erreurs sont très difficile à reproduire, l'utilisation de mock permet ici de simuler une erreur pour pouvoir traiter ce cas et donc améliorer la couverture de code, par exemple le catch d'une exception ; - sans l'utilisation de mock, le test peut retourner une erreur ne provenant pas du code qui est testé (par exemple une base de données). Cependant, une utilisation abusive de mock peut avoir l'effet inverse, notamment allonger le temps d'exécution des tests, rendre les tests compliqués à comprendre et à maintenir. ## Génération \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=10 "Modifier la section : Génération") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=10 "Modifier le code source de la section : Génération")\] La plupart des [frameworks](https://fr.wikipedia.org/wiki/Framework "Framework") de la famille [xUnit](https://fr.wikipedia.org/wiki/XUnit "XUnit") permettent la génération des classes de test unitaire. Cependant ces frameworks ne fournissent que le squelette des classes. Les tests devront donc être écrits par le développeur. La génération de tests unitaires est un sujet important pour les chercheurs et plusieurs conférences s'intéressent à cette problématique, telles que [International Symposium on Software Testing and Analysis](https://fr.wikipedia.org/w/index.php?title=International_Symposium_on_Software_Testing_and_Analysis&action=edit&redlink=1 "International Symposium on Software Testing and Analysis (page inexistante)") (ISSTA), [International Conference on Software Engineering](https://fr.wikipedia.org/w/index.php?title=International_Conference_on_Software_Engineering&action=edit&redlink=1 "International Conference on Software Engineering (page inexistante)") (ICSE) et [Automated Software Engineering](https://fr.wikipedia.org/w/index.php?title=Automated_Software_Engineering&action=edit&redlink=1 "Automated Software Engineering (page inexistante)") (ASE). ### Correction de test unitaire \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=11 "Modifier la section : Correction de test unitaire") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=11 "Modifier le code source de la section : Correction de test unitaire")\] Lors d'une modification dans le code d'un programme, il se peut que certains tests ne passent plus ; dans ce cas, le développeur doit déterminer si cela vient du code en lui-même ou du test : si cela vient du test, le développeur doit modifier son test car la suppression de celui-ci entraînerait une augmentation des chances de régression du programme. Certains chercheurs ont développé des outils pour résoudre ce problème. ReAssert[\[14\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-14) est un outil suggérant des réparations pour un test qui échoue, il analyse les tests à modifier et suggère des changements au développeur, si cette suggestion convient au développeur, il peut effectuer le changement en cliquant sur un bouton. ### Test unitaire paramétrable \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=12 "Modifier la section : Test unitaire paramétrable") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=12 "Modifier le code source de la section : Test unitaire paramétrable")\] Les tests unitaires paramétrables sont des tests unitaires qui prennent des paramètres. Ils peuvent ensuite utiliser des outils comme QuickCheck pour générer des paramètres. Ces tests sont supportés par [JUnit](https://fr.wikipedia.org/wiki/JUnit "JUnit"), [TestNG](https://fr.wikipedia.org/wiki/TestNG "TestNG") et NUnit. En s'appuyant sur des cas concrets d'entrée et sortie, la génération d'Oracle et sur la couverture de test pour minimiser les cas, des chercheurs ont réussi à générer des tests unitaires paramétrables[\[15\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-15). Les résultats de cette méthode sont prometteurs. ## Environnements de développement \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=13 "Modifier la section : Environnements de développement") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=13 "Modifier le code source de la section : Environnements de développement")\] Il existe une multitude de cadriciels ([framework](https://fr.wikipedia.org/wiki/Framework "Framework")) permettant de réaliser facilement des tests unitaires. Il en existe dans les principaux [langages de programmation](https://fr.wikipedia.org/wiki/Langage_de_programmation "Langage de programmation"). Par exemple `Test::More`[\[16\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-16) pour le [Perl](https://fr.wikipedia.org/wiki/Langage_Perl "Langage Perl"). ### Frameworks xUnit \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=14 "Modifier la section : Frameworks xUnit") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=14 "Modifier le code source de la section : Frameworks xUnit")\] Le terme générique « [xUnit](https://fr.wikipedia.org/wiki/XUnit "XUnit") » désigne un outil permettant de réaliser des tests unitaires dans un langage donné (dont l'initiale remplace « x » le plus souvent). - AUnit[\[17\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-17) pour [Ada](https://fr.wikipedia.org/wiki/Ada_\(langage\) "Ada (langage)") ; - ASUnit[\[18\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-18) pour [ActionScript](https://fr.wikipedia.org/wiki/ActionScript "ActionScript") ; - Cppunit[\[19\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-19) pour [C++](https://fr.wikipedia.org/wiki/C%2B%2B "C++") ; - CUnit[\[20\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-20) pour [C](https://fr.wikipedia.org/wiki/C_\(langage\) "C (langage)") ; - DUnit pour [Delphi](https://fr.wikipedia.org/wiki/Embarcadero_Delphi "Embarcadero Delphi") ; - FLEXunit pour [Adobe Flex](https://fr.wikipedia.org/wiki/Adobe_Flex "Adobe Flex") ; - [Google](https://fr.wikipedia.org/wiki/Google "Google") Test[\[21\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-21) et Boost Test[\[22\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-22) pour [C++](https://fr.wikipedia.org/wiki/C%2B%2B "C++") ; - HUnit[\[23\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-23) pour [Haskell](https://fr.wikipedia.org/wiki/Haskell "Haskell") ; - JSUnit[\[24\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-24), QUnit[\[25\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-25), [Unit.js](https://fr.wikipedia.org/wiki/Unit.js "Unit.js")[\[26\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-26) et Jest[\[27\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-27) pour [JavaScript](https://fr.wikipedia.org/wiki/JavaScript "JavaScript") ; - [JUnit](https://fr.wikipedia.org/wiki/JUnit "JUnit")[\[28\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-28) et [TestNG](https://fr.wikipedia.org/wiki/TestNG "TestNG")[\[29\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-29) pour [Java](https://fr.wikipedia.org/wiki/Java_\(langage\) "Java (langage)") ; - NUnit[\[30\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-30) pour [.NET](https://fr.wikipedia.org/wiki/Microsoft_.NET "Microsoft .NET") ; - [Microsoft](https://fr.wikipedia.org/wiki/Microsoft "Microsoft") Unit Test[\[31\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-31) pour [.NET](https://fr.wikipedia.org/wiki/Microsoft_.NET "Microsoft .NET") ; - xUnit[\[32\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-32) pour [.NET](https://fr.wikipedia.org/wiki/Microsoft_.NET "Microsoft .NET") ; - NUnitASP[\[33\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-33) pour [ASP.NET](https://fr.wikipedia.org/wiki/ASP.NET "ASP.NET") (support interrompu depuis le 31 janvier 2008 ) ; - OUnit[\[34\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-34) pour [OCaml](https://fr.wikipedia.org/wiki/OCaml "OCaml") ; - OCunit pour [Objective C](https://fr.wikipedia.org/wiki/Objective_C "Objective C") ; - PBUnit pour [PowerBuilder](https://fr.wikipedia.org/wiki/PowerBuilder "PowerBuilder") ; - [PHPUnit](https://fr.wikipedia.org/wiki/PHPUnit "PHPUnit")[\[35\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-35), SimpleTest[\[36\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-36) et Atoum[\[37\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-37) pour [PHP](https://fr.wikipedia.org/wiki/PHP "PHP") ; - plunit pour [Prolog](https://fr.wikipedia.org/wiki/Prolog "Prolog") ; - utPLSQL[\[38\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-38) pour [PL/SQL](https://fr.wikipedia.org/wiki/PL/SQL "PL/SQL") ; - Unittest et [PyUnit](https://fr.wikipedia.org/wiki/PyUnit "PyUnit") pour [Python](https://fr.wikipedia.org/wiki/Python_\(langage\) "Python (langage)") ; - [Tape](https://fr.wikipedia.org/wiki/Tape_\(framework_de_tests_JavaScript\) "Tape (framework de tests JavaScript)") pour [JavaScript](https://fr.wikipedia.org/wiki/JavaScript "JavaScript") ; - Test::Unit pour [Ruby](https://fr.wikipedia.org/wiki/Ruby "Ruby") ; - Test::More pour [Perl](https://fr.wikipedia.org/wiki/Langage_Perl "Langage Perl") ; - [Typemock](https://fr.wikipedia.org/w/index.php?title=Typemock&action=edit&redlink=1 "Typemock (page inexistante)") pour .NET, C++, C\#. Avec Typemock vous pouvez travailler sur legacy code aussi. - SUnit[\[39\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-39) pour [Smalltalk](https://fr.wikipedia.org/wiki/Smalltalk "Smalltalk") ; - RPGUnit[\[40\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-40) pour RPG ; - ScalaTest pour Scala - SASUnit[\[41\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-41) pour [SAS](https://fr.wikipedia.org/wiki/SAS_\(langage\) "SAS (langage)"). ## Outils commerciaux \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=15 "Modifier la section : Outils commerciaux") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=15 "Modifier le code source de la section : Outils commerciaux")\] Divers outils permettent l'automatisation des tests unitaires : - Le module TBrun de la suite d'outils [LDRA](https://fr.wikipedia.org/wiki/LDRA "LDRA") ; - Tessy (distribution : Hitex Development Tools/Allemagne). - Ponicode, génération de tests unitaires en Javascript[\[42\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-42). ## Articles connexes \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=16 "Modifier la section : Articles connexes") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=16 "Modifier le code source de la section : Articles connexes")\] Sur les autres projets Wikimedia : - [Test unitaire](https://fr.wikibooks.org/wiki/Introduction_au_test_logiciel/Tests_unitaires "b:Introduction au test logiciel/Tests unitaires"), sur Wikibooks - [Cycle en V](https://fr.wikipedia.org/wiki/Cycle_en_V "Cycle en V") - [Test](https://fr.wikipedia.org/wiki/Test_\(informatique\) "Test (informatique)") - [Extreme programming](https://fr.wikipedia.org/wiki/Extreme_programming "Extreme programming") - [Test Driven Development](https://fr.wikipedia.org/wiki/Test_Driven_Development "Test Driven Development") ## Notes \[[modifier](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&veaction=edit&section=17 "Modifier la section : Notes") \\| [modifier le code](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&action=edit&section=17 "Modifier le code source de la section : Notes")\] 1. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-1) (en) Benington, Herbert D., « Production of large computer programs », Proceedings of the Symposium on Advanced Programming Methods for Digital Computers, Washington, D.C., June 28-29, 1956, Office of Naval Research, Department of the Navy,‎ 1956 , p. 15-28 2. ↑ [a](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-:0_2-0) et [b](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-:0_2-1) H. D. Benington, « Production of large computer programs », Proceedings of the 9th international conference on Software Engineering, IEEE Computer Society Press, iCSE '87,‎ 1er mars 1987 , p. 299–310 ([ISBN](https://fr.wikipedia.org/wiki/International_Standard_Book_Number "International Standard Book Number") [978-0-89791-216-7](https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Ouvrages_de_r%C3%A9f%C3%A9rence/978-0-89791-216-7 "Spécial:Ouvrages de référence/978-0-89791-216-7"), [DOI](https://fr.wikipedia.org/wiki/Digital_Object_Identifier "Digital Object Identifier") [10\.5555/41765.41799](https://dx.doi.org/10.5555/41765.41799), [lire en ligne](https://dl.acm.org/doi/10.5555/41765.41799), consulté le 3 avril 2024 ) 3. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-3) Norman A. Zimmerman, « System integration as a programming function », Proceedings of the 1969 24th national conference, Association for Computing Machinery, aCM '69,‎ 26 août 1969 , p. 459–467 ([ISBN](https://fr.wikipedia.org/wiki/International_Standard_Book_Number "International Standard Book Number") [978-1-4503-7493-4](https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Ouvrages_de_r%C3%A9f%C3%A9rence/978-1-4503-7493-4 "Spécial:Ouvrages de référence/978-1-4503-7493-4"), [DOI](https://fr.wikipedia.org/wiki/Digital_Object_Identifier "Digital Object Identifier") [10\.1145/800195.805951](https://dx.doi.org/10.1145/800195.805951), [lire en ligne](https://dl.acm.org/doi/10.1145/800195.805951), consulté le 3 avril 2024 ) 4. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-4) (en) Gouvernement des Etats Unis d'Amérique, Département de la Défence, MIL-STD-483 Military standard: configuration management practices for systems, equipment, munitions, and computer programs , 31 décembre 1970 , Section 3.4.7.2. "The contractor shall then code and test software Units, and enter the source and object code, and associated listings of each successfully tested Unit into the Developmental Configuration" 5. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-5) (en) Michael F. Tighe, « The value of a proper software quality assurance methodology », ACM SIGMETRICS Performance Evaluation Review, vol. 7, nos 3-4,‎ novembre 1978 , p. 165–172 ([ISSN](https://fr.wikipedia.org/wiki/International_Standard_Serial_Number "International Standard Serial Number") [0163-5999](https://portal.issn.org/resource/issn/0163-5999), [DOI](https://fr.wikipedia.org/wiki/Digital_Object_Identifier "Digital Object Identifier") [10\.1145/1007775.811118](https://dx.doi.org/10.1145/1007775.811118), [lire en ligne](https://dl.acm.org/doi/10.1145/1007775.811118), consulté le 3 avril 2024 ) 6. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-6) [Camp Smalltalk SUnit](http://sunit.sourceforge.net/) 7. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-7) [Simple Smalltalk Testing:With Patterns](http://www.xprogramming.com/testfram.htm), in Smalltalk Report octobre 1994, Kent Beck 8. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-8) (en) Ward Cunningham, « [Testing Framework](http://wiki.c2.com/?TestingFramework) » ![Accès libre](https://upload.wikimedia.org/wikipedia/commons/thumb/6/65/Lock-green.svg/20px-Lock-green.svg.png), sur wiki.c2.com . 9. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-9) [Xunit, Martin Fowler](http://www.martinfowler.com/bliki/Xunit.html) 10. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-10) GNU Based Compilation System for Space Embedded Applications, Blondin, J. P. & Martignano, M., DASIA 98 - Data Systems in Aerospace, Proceedings of the conference held 25-28 May, 1998 in Athens, Greece, Edited by B. Kaldeich-Schü.rmann. ESA SP-422. Paris: European Space Agency, 1998., p.137, "1998ESASP.422..137B", page 138 <http://adsbit.harvard.edu//full/1998ESASP.422..137B/0000138.000.html> 11. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-11) [Unit Testing Best Practices, Roy Osherove](https://fr.wikipedia.org/wiki/Programmation_informatique "Programmation informatique"). 12. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-12) [Test First, bob Martin](http://blog.8thlight.com/uncle-bob/2013/09/23/Test-first.html). 13. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-13) Robert Martin, When to Mock. 14. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-14) (en) Brett Daniel, Danny Dig, Tihomir Gvero, Vilas Jagannath, Johnston Jiaa, Damion Mitchell, Jurand Nogiec, Shin Hwei Tan et Darko Marinov, « ReAssert: a tool for repairing broken unit tests », ICSE,‎ 2011 ([lire en ligne](http://dl.acm.org/citation.cfm?doid=1985793.1985978)) . 15. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-15) (en) Gordon Fraser et Andreas Zeller, « Generating Parameterized Unit Tests », ISSTA,‎ 2011 ([lire en ligne](http://dl.acm.org/citation.cfm?doid=2001420.2001464)) . 16. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-16) [Test::More sur CPAN](https://metacpan.org/module/Test::More), entre autres [modules de tests](https://metacpan.org/search?q=Test). Voir aussi les articles de l'association des mongueurs de Perl dans [Linux Magazine France](https://fr.wikipedia.org/wiki/Linux_Magazine_France "Linux Magazine France") disponibles sur <http://articles.mongueurs.net/magazines> 17. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-17) [AUnit](https://libre.adacore.com/aunit/main.html) 18. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-18) [AsUnit](http://www.asunit.org/) 19. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-19) [CppUnit](http://cppunit.sourceforge.net/) et en [version 2](https://launchpad.net/cppunit2) 20. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-20) [CUnit](http://cunit.sourceforge.net/) 21. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-21) [GoogleTest](https://code.google.com/p/googletest/) 22. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-22) [Boost.Test](http://www.boost.org/doc/libs/release/libs/test/index.html) 23. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-23) [HUnit](http://hunit.sourceforge.net/) 24. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-24) [JsUnit](http://www.jsunit.net/) 25. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-25) <http://qunitjs.com> Unit testing for Javascript made by the jQuery Foundation 26. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-26) (en) [Unit JS](http://unitjs.com/) : « Unit testing framework for Javascript ». 27. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-27) (en) « [Jest · 🃏 Delightful JavaScript Testing](https://jestjs.io/) », sur jestjs.io (consulté le 2 mars 2020 ) . 28. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-28) [Welcome to The New JUnit.org! \\| JUnit.org](http://junit.org/). 29. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-29) (en) « [TestNG Documentation](http://testng.org/) », sur testng.org (consulté le 21 mai 2024 ) . 30. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-30) [NUnit - Home](http://www.nunit.org/) 31. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-31) (en-US) erickson-doug, « [Writing Unit Tests for the .NET Framework with the Microsoft Unit Test Framework for Managed Code - Visual Studio](https://docs.microsoft.com/fr-fr/visualstudio/test/writing-unit-tests-for-the-dotnet-framework-with-the-microsoft-unit-test-framework-for-managed-code?view=vs-2015) », sur docs.microsoft.com (consulté le 4 septembre 2018 ) . 32. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-32) (en) « [Home \> xUnit.net](https://xunit.github.io/) », sur xunit.github.io (consulté le 4 septembre 2018 ) . 33. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-33) [NUnitAsp - ASP.NET unit testing](http://nunitasp.sourceforge.net/) 34. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-34) [OUnit](http://ounit.forge.ocamlcore.org/) 35. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-35) [PHPUnit - Trac](https://www.phpunit.de/) 36. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-36) [SimpleTest - Unit Testing for PHP](http://www.simpletest.org/) 37. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-37) [Atoum](http://www.atoum.org/) 38. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-38) [utPLSQL](http://utplsql.sourceforge.net/) 39. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-39) [Simple Smalltalk Testing: With Patterns](http://www.xprogramming.com/testfram.htm) 40. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-40) <http://rpgunit.sourceforge.net/> 41. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-41) (en) « [SASUnit](https://sourceforge.net/projects/sasunit/) », sur SourceForge (consulté le 24 février 2020 ) . 42. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-42) (en) « [Ponicode - Quick and easy Javascript unit testing](https://ponicode.com/) », sur ponicode.com (consulté le 23 juin 2020 ) . \| [v](https://fr.wikipedia.org/wiki/Mod%C3%A8le:Palette_Qualit%C3%A9_logicielle "Modèle:Palette Qualité logicielle") · [m](https://fr.wikipedia.org/w/index.php?title=Mod%C3%A8le:Palette_Qualit%C3%A9_logicielle&action=edit)Gestion de la [qualité logicielle](https://fr.wikipedia.org/wiki/Qualit%C3%A9_logicielle "Qualité logicielle") \| \| \|---\|---\| \| [Indicateurs de qualité](https://fr.wikipedia.org/wiki/Qualit%C3%A9_logicielle#Indicateurs_de_qualit%C3%A9_logicielle "Qualité logicielle") ([ISO/CEI 9126](https://fr.wikipedia.org/wiki/ISO/CEI_9126 "ISO/CEI 9126")) \| Capacité fonctionnelle (réponse aux [exigences](https://fr.wikipedia.org/wiki/Exigence_\(ing%C3%A9nierie\) "Exigence (ingénierie)")) [Fiabilité](https://fr.wikipedia.org/wiki/Fiabilit%C3%A9 "Fiabilité") [Maintenabilité](https://fr.wikipedia.org/wiki/Maintenabilit%C3%A9 "Maintenabilité") [Performance](https://fr.wikipedia.org/wiki/Performances_\(informatique\) "Performances (informatique)") [Portabilité](https://fr.wikipedia.org/wiki/Portabilit%C3%A9_\(informatique\) "Portabilité (informatique)") [Utilisabilité](https://fr.wikipedia.org/wiki/Utilisabilit%C3%A9 "Utilisabilité") \| \| Compréhension et contrôle du [code source](https://fr.wikipedia.org/wiki/Code_source "Code source") \| \| \| \| \| \| [Tests](https://fr.wikipedia.org/wiki/Test_\(informatique\) "Test (informatique)") \| [Acceptation](https://fr.wikipedia.org/wiki/Test_d%27acceptation "Test d'acceptation") [Intégration](https://fr.wikipedia.org/wiki/Test_d%27int%C3%A9gration "Test d'intégration") [Performance](https://fr.wikipedia.org/wiki/Test_de_performance "Test de performance") [Régression](https://fr.wikipedia.org/wiki/Test_de_r%C3%A9gression "Test de régression") [Unitaire]() [Utilisateur](https://fr.wikipedia.org/wiki/Test_utilisateur "Test utilisateur") [Validation](https://fr.wikipedia.org/wiki/Test_de_validation "Test de validation") \| \| [Métriques](https://fr.wikipedia.org/wiki/M%C3%A9trique_\(logiciel\) "Métrique (logiciel)") \| [Cohésion](https://fr.wikipedia.org/wiki/Coh%C3%A9sion_\(informatique\) "Cohésion (informatique)") [Couplage](https://fr.wikipedia.org/wiki/Couplage_\(informatique\) "Couplage (informatique)") [Couverture de code](https://fr.wikipedia.org/wiki/Couverture_de_code "Couverture de code") [Halstead](https://fr.wikipedia.org/wiki/M%C3%A9triques_d%27Halstead "Métriques d'Halstead") [Indépendance fonctionnelle](https://fr.wikipedia.org/wiki/Ind%C3%A9pendance_fonctionnelle "Indépendance fonctionnelle") [Indice de maintenabilité](https://fr.wikipedia.org/wiki/Indice_de_maintenabilit%C3%A9 "Indice de maintenabilité") [Ligne de code](https://fr.wikipedia.org/wiki/Ligne_de_code "Ligne de code") [Nombre cyclomatique](https://fr.wikipedia.org/wiki/Nombre_cyclomatique "Nombre cyclomatique") [Point de fonction](https://fr.wikipedia.org/wiki/Point_de_fonction "Point de fonction") \| \| Remaniements \| [Maintenance](https://fr.wikipedia.org/wiki/Maintenance_du_logiciel "Maintenance du logiciel") [Optimisation de code](https://fr.wikipedia.org/wiki/Optimisation_de_code "Optimisation de code") [Réusinage de code](https://fr.wikipedia.org/wiki/R%C3%A9usinage_de_code "Réusinage de code") ([Règle de trois](https://fr.wikipedia.org/wiki/R%C3%A8gle_de_trois_\(programmation_informatique\) "Règle de trois (programmation informatique)")) \| \| Principes de [programmation](https://fr.wikipedia.org/wiki/Programmation_informatique "Programmation informatique") \| \| \| \| \| \| [SOLID](https://fr.wikipedia.org/wiki/SOLID_\(informatique\) "SOLID (informatique)") \| [Responsabilité unique](https://fr.wikipedia.org/wiki/Principe_de_responsabilit%C3%A9_unique "Principe de responsabilité unique") [Ouvert/fermé](https://fr.wikipedia.org/wiki/Principe_ouvert/ferm%C3%A9 "Principe ouvert/fermé") [Substitution de Liskov](https://fr.wikipedia.org/wiki/Principe_de_substitution_de_Liskov "Principe de substitution de Liskov") [Ségrégation des interfaces](https://fr.wikipedia.org/wiki/Principe_de_s%C3%A9gr%C3%A9gation_des_interfaces "Principe de ségrégation des interfaces") [Inversion des dépendances](https://fr.wikipedia.org/wiki/Inversion_des_d%C3%A9pendances "Inversion des dépendances") \| \| Mauvaises pratiques \| \| \| \| \| \| [Antipatterns](https://fr.wikipedia.org/wiki/Antipattern "Antipattern") \| [Attente active](https://fr.wikipedia.org/wiki/Attente_active "Attente active") [Grosse boule de boue](https://fr.wikipedia.org/wiki/Grosse_boule_de_boue "Grosse boule de boue") [Programmation spaghetti](https://fr.wikipedia.org/wiki/Programmation_spaghetti "Programmation spaghetti") ([syndrome](https://fr.wikipedia.org/wiki/Syndrome_du_plat_de_spaghettis "Syndrome du plat de spaghettis")) [Réinventer la roue](https://fr.wikipedia.org/wiki/R%C3%A9inventer_la_roue "Réinventer la roue") \| \| \| \| \| [Code smells](https://fr.wikipedia.org/wiki/Code_smell "Code smell") \| [Duplication de code](https://fr.wikipedia.org/wiki/Duplication_de_code "Duplication de code") [God object](https://fr.wikipedia.org/wiki/God_object "God object") \| \| Voir aussi : [Génie logiciel](https://fr.wikipedia.org/wiki/G%C3%A9nie_logiciel "Génie logiciel"), [Software craftsmanship](https://fr.wikipedia.org/wiki/Software_craftsmanship "Software craftsmanship"), [Dégradation logicielle](https://fr.wikipedia.org/wiki/D%C3%A9gradation_logicielle "Dégradation logicielle") \| \| - [![icône décorative](https://upload.wikimedia.org/wikipedia/commons/thumb/0/02/Circle-icons-computer.svg/40px-Circle-icons-computer.svg.png)](https://fr.wikipedia.org/wiki/Portail:Informatique "Portail de l’informatique") [Portail de l’informatique](https://fr.wikipedia.org/wiki/Portail:Informatique "Portail:Informatique") ![](https://fr.wikipedia.org/wiki/Special:CentralAutoLogin/start?useformat=desktop&type=1x1&usesul3=1) Ce document provient de « <https://fr.wikipedia.org/w/index.php?title=Test_unitaire&oldid=233485497> ». [Catégorie](https://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Accueil "Catégorie:Accueil") : - [Test logiciel](https://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Test_logiciel "Catégorie:Test logiciel") Catégories cachées : - [Portail:Informatique/Articles liés](https://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Portail:Informatique/Articles_li%C3%A9s "Catégorie:Portail:Informatique/Articles liés") - [Portail:Technologies/Articles liés](https://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Portail:Technologies/Articles_li%C3%A9s "Catégorie:Portail:Technologies/Articles liés") - La dernière modification de cette page a été faite le 21 février 2026 à 12:01. - [Droit d'auteur](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Citation_et_r%C3%A9utilisation_du_contenu_de_Wikip%C3%A9dia "Wikipédia:Citation et réutilisation du contenu de Wikipédia") : les textes sont disponibles sous [licence Creative Commons attribution, partage dans les mêmes conditions](https://creativecommons.org/licenses/by-sa/4.0/deed.fr) ; d’autres conditions peuvent s’appliquer. Voyez les [conditions d’utilisation](https://foundation.wikimedia.org/wiki/Policy:Terms_of_Use/fr) pour plus de détails, ainsi que les [crédits graphiques](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Cr%C3%A9dits_graphiques "Wikipédia:Crédits graphiques"). En cas de réutilisation des textes de cette page, voyez [comment citer les auteurs et mentionner la licence](https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Citer/Test_unitaire "Spécial:Citer/Test unitaire"). Wikipedia® est une marque déposée de la [Wikimedia Foundation, Inc.](https://wikimediafoundation.org/), organisation de bienfaisance régie par le paragraphe [501(c)(3)](https://fr.wikipedia.org/wiki/501c "501c") du code fiscal des États-Unis. - [Politique de confidentialité](https://foundation.wikimedia.org/wiki/Special:MyLanguage/Policy:Privacy_policy/fr) - [À propos de Wikipédia](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:%C3%80_propos_de_Wikip%C3%A9dia) - [Avertissements](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Avertissements_g%C3%A9n%C3%A9raux) - [Contact](https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Contact) - [Contacts juridiques & sécurité](https://foundation.wikimedia.org/wiki/Special:MyLanguage/Legal:Wikimedia_Foundation_Legal_and_Safety_Contact_Information) - [Code de conduite](https://foundation.wikimedia.org/wiki/Special:MyLanguage/Policy:Universal_Code_of_Conduct) - [Développeurs](https://developer.wikimedia.org/) - [Statistiques](https://stats.wikimedia.org/#/fr.wikipedia.org) - [Déclaration sur les témoins (cookies)](https://foundation.wikimedia.org/wiki/Special:MyLanguage/Policy:Cookie_statement) - [Version mobile](https://fr.wikipedia.org/w/index.php?title=Test_unitaire&mobileaction=toggle_view_mobile) - [![Wikimedia Foundation](https://fr.wikipedia.org/static/images/footer/wikimedia.svg)](https://www.wikimedia.org/) - [![Powered by MediaWiki](https://fr.wikipedia.org/w/resources/assets/mediawiki_compact.svg)](https://www.mediawiki.org/) Rechercher Basculer la table des matières Test unitaire 29 langues [Ajouter un sujet](https://fr.wikipedia.org/wiki/Test_unitaire)
Readable Markdown	Un article de Wikipédia, l'encyclopédie libre. En [programmation informatique](https://fr.wikipedia.org/wiki/Programmation_informatique "Programmation informatique"), le test unitaire (ou TU, voire *UT* pour Unit Testing en anglais) est une procédure permettant de vérifier le bon fonctionnement d'une partie précise d'un [logiciel](https://fr.wikipedia.org/wiki/Logiciel "Logiciel") ou d'une portion d'un [programme](https://fr.wikipedia.org/wiki/Programme_informatique "Programme informatique") (appelée « unité » ou « module »). Dans les applications non critiques, l'écriture des tests unitaires a longtemps été considérée comme une tâche secondaire. Cependant, les méthodes [extreme programming](https://fr.wikipedia.org/wiki/Extreme_programming "Extreme programming") (XP) et [test driven development](https://fr.wikipedia.org/wiki/Test_driven_development "Test driven development") (TDD) ont remis les tests unitaires, appelés « tests du programmeur », au centre de l'activité de programmation. Les tests unitaires, en tant que principe de tester séparément des parties plus élémentaires d'un logiciel complexe, remonte aux débuts de l'[ingénierie logicielle](https://fr.wikipedia.org/wiki/Ing%C3%A9nierie_logicielle "Ingénierie logicielle"). En Juin 1956, H.D. Benington présente en effet le projet [SAGE](https://fr.wikipedia.org/wiki/Semi-Automatic_Ground_Environment "Semi-Automatic Ground Environment") au symposium sur les méthodes de programmation avancée organisé par la [marine américaine](https://fr.wikipedia.org/wiki/United_States_Navy "United States Navy"). L'approche utilisée prévoyait à l'issue de la phase de codage une étape de « tests de paramètres » pour valider la conformité des sous-programmes et composants à leur spécifications, avant de procéder à un « test d'assemblage » de ces composants[\[1\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-1),[\[2\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-:0-2). En 1964, une approche similaire est décrite pour les logiciels du [programme Mercury](https://fr.wikipedia.org/wiki/Programme_Mercury "Programme Mercury") : les unités individuelles développées par différentes organisations étaient soumises à des "tests unitaires" avant d'être intégrées entre elles. En 1969, les méthodologies de tests sont structurées encore davantage, avec des tests unitaires, des tests de composants, et des [tests d'intégration](https://fr.wikipedia.org/wiki/Test_d%27int%C3%A9gration "Test d'intégration"), dans le but de valider des parties élémentaires du logiciel séparément, puis de vérifier le bon fonctionnement des assemblages progressif en blocs plus larges[\[3\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-3). Des normes publiques adoptées à la fin des années 60, telles que les standards militaires MIL-STD-483[\[4\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-4) et MIL-STD-490 de l'armée américaine contribuent à une large reconnaissance et adoption des tests unitaires au sein de gros projets. Les tests unitaires étaient alors interactifs[\[2\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-:0-2), ou automatisés[\[5\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-5), utilisant soit des tests programmés ou des outils de capture et répétition automatisés. En 1994 [Kent Beck](https://fr.wikipedia.org/wiki/Kent_Beck "Kent Beck") décrit un environnement cadre de test pour le langage [Smalltalk](https://fr.wikipedia.org/wiki/Smalltalk "Smalltalk"), qui deviendra [SUnit](https://fr.wikipedia.org/w/index.php?title=SUnit&action=edit&redlink=1 "SUnit (page inexistante)")[\[6\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-6) par la suite[\[7\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-7),[\[8\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-8). En 1997, [Kent Beck](https://fr.wikipedia.org/wiki/Kent_Beck "Kent Beck") rencontre [Erich Gamma](https://fr.wikipedia.org/wiki/Erich_Gamma "Erich Gamma") avec lequel il crée [JUnit](https://fr.wikipedia.org/wiki/JUnit "JUnit") qui, par sa popularité, entraînera la création de nombreux [frameworks](https://fr.wikipedia.org/wiki/Frameworks "Frameworks") de tests unitaires, cet ensemble se nomme [xUnit](https://fr.wikipedia.org/wiki/XUnit "XUnit")[\[9\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-9). À la même époque, ATTOL Unit test est développé, puis utilisé par [Sextant Avionique](https://fr.wikipedia.org/wiki/Sextant_Avionique "Sextant Avionique") en 1998[\[10\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-10) On écrit un test pour confronter une réalisation à sa [spécification](https://fr.wikipedia.org/wiki/Sp%C3%A9cification_fonctionnelle "Spécification fonctionnelle"). Le [test](https://fr.wikipedia.org/wiki/Test_\(informatique\) "Test (informatique)") définit un critère d'arrêt (état ou sorties à l'issue de l'exécution) et permet de statuer sur le succès ou sur l'échec d'une vérification. Grâce à la spécification, on est en mesure de faire correspondre un état d'entrée donné à un résultat ou à une sortie. Le [test](https://fr.wikipedia.org/wiki/Test_\(informatique\) "Test (informatique)") permet de vérifier que la relation d'entrée / sortie donnée par la spécification est bel et bien réalisée. La méthode XP préconise d'écrire les tests en même temps, ou même avant la fonction à tester ([Test Driven Development](https://fr.wikipedia.org/wiki/Test_Driven_Development "Test Driven Development")). Ceci permet de définir précisément l'interface du module à développer. Les tests sont exécutés durant tout le développement, permettant de visualiser si le code fraîchement écrit correspond au besoin. Lors d'une modification d'un programme, les tests unitaires signalent les éventuelles [régressions](https://fr.wikipedia.org/wiki/Test_de_r%C3%A9gression "Test de régression"). En effet, certains tests peuvent échouer à la suite d'une modification, il faut donc soit réécrire le test pour le faire correspondre aux nouvelles attentes, soit corriger l'erreur se situant dans le code. Les tests unitaires peuvent servir de complément à [l'API](https://fr.wikipedia.org/wiki/Interface_de_programmation "Interface de programmation"), il est très utile de lire les tests pour comprendre comment s'utilise une méthode. De plus, il est possible que la documentation ne soit plus à jour, mais les tests eux correspondent à la réalité de l'application. On définit généralement 4 phases dans l'exécution d'un test unitaire : 1. Initialisation (fonction `setUp`) : définition d'un environnement de test complètement reproductible (une [fixture](https://fr.wikipedia.org/wiki/Test_fixture "Test fixture")). 2. Exercice : le module à tester est exécuté. 3. Vérification (utilisation de fonctions `assert`) : comparaison des résultats obtenus avec un vecteur de résultat défini. Ces tests définissent le résultat du test : SUCCÈS (`SUCCESS`) ou ÉCHEC (`FAILURE`). On peut également définir d'autres résultats comme ÉVITÉ (`SKIPPED`). 4. Désactivation (fonction `tearDown`) : désinstallation des [fixtures](https://fr.wikipedia.org/wiki/Test_fixture "Test fixture") pour retrouver l'état initial du système, dans le but de ne pas polluer les tests suivants. Tous les tests doivent être indépendants et reproductibles unitairement (quand exécutés seuls). Il s'agit pour le programmeur de tester un [module](https://fr.wikipedia.org/wiki/Module_\(programmation\) "Module (programmation)"), indépendamment du reste du programme, ceci afin de s'assurer qu'il réponde aux [spécifications fonctionnelles](https://fr.wikipedia.org/wiki/Sp%C3%A9cification_\(informatique\) "Spécification (informatique)") et qu'il fonctionne correctement en toutes circonstances. Cette vérification est considérée comme essentielle, en particulier dans les applications critiques. Elle s'accompagne couramment d'une vérification de la [couverture de code](https://fr.wikipedia.org/wiki/Couverture_de_code "Couverture de code") (évaluation de la couverture structurelle), qui consiste à s'assurer que l'ensemble des [tests](https://fr.wikipedia.org/wiki/Test_\(informatique\) "Test (informatique)") conduit à exécuter l'ensemble (ou une fraction déterminée) des instructions présentes dans le code. L'ensemble des tests unitaires doit être rejoué après une modification du code afin de vérifier qu'il n'y a pas de [régressions](https://fr.wikipedia.org/wiki/Non-r%C3%A9gression "Non-régression") (l'apparition de nouveaux dysfonctionnements). L'emploi d'une « stratégie de test » particulière peut limiter les tests à rejouer, par exemple : une analyse d'impact des modifications, corrélée à une preuve d'indépendance des modules, permet de cibler les cas de test unitaire à rejouer. Un test doit correspondre aux spécifications de l'application, il faut donc écrire les tests en premier puis les faire passer par la suite plutôt que d'écrire le code avant et de prendre le risque d'être influencé par celui-ci lors de la rédaction des tests[\[11\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-11). Bob Martin[\[12\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-12), grand défenseur de la méthode [TDD](https://fr.wikipedia.org/wiki/Test_Driven_Development "Test Driven Development"), propose un [modèle](https://fr.wikipedia.org/wiki/Pattern "Pattern") simple pour l'écriture des tests unitaires : 1. Écrire une fonction de test qui doit obtenir un résultat défini dans les spécifications. Ce code appelant un code qui n'existe pas encore, celui-ci doit échouer. Ceci a pour but de définir une fonction qui teste « quelque chose ». 2. Écrire le code (le minimum de « quelque chose ») pour faire réussir le test. 3. Une fois le test en succès, rajouter un autre test pour obtenir un résultat légèrement différent, en faisant varier les entrées par exemple. Ce nouveau test fera faillir le code principal. 4. Modifier le code principal pour faire réussir les tests. 5. Recommencer, en éliminant et [refactorisant](https://fr.wikipedia.org/wiki/R%C3%A9usinage_de_code "Réusinage de code") les éventuelles redondances dans le code des tests. On refactorise en même temps le code principal que le code des tests. 6. Un test unitaire doit tester une caractéristique et une seule. On ne définit pas un « [scénario](https://fr.wikipedia.org/wiki/Sc%C3%A9nario_\(informatique\) "Scénario (informatique)") » de test complexe dans un test unitaire. 7. Il est déconseillé de tester les détails d'implémentation telles que les fonctions privées d'une classe, on se concentrera à tester les fonctions publiques, c'est-à-dire les interfaces avec lesquelles les acteurs extérieurs interagissent. Ainsi, on découple les tests de l'implémentation et on se concentre sur la vérification du comportement attendu tout en gardant une flexibilité sur la manière d'arriver au résultat souhaité. Les [mocks](https://fr.wikipedia.org/wiki/Mock_\(programmation_orient%C3%A9e_objet\) "Mock (programmation orientée objet)") sont des objets permettant de simuler un objet réel de façon contrôlée. Dans certains cas, l'utilisation de mock est primordiale, pour un gain de temps de [couverture de code](https://fr.wikipedia.org/wiki/Couverture_de_code "Couverture de code"), et de fiabilité des tests[\[13\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-13) - pour simuler une [base de données](https://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es "Base de données"), un [service web](https://fr.wikipedia.org/wiki/Service_web "Service web"), etc., les interactions entre l'application et ces outils prennent du temps, l'utilisation de mock pour simuler leurs fonctionnements peut être un gain de temps considérable ; - certains cas d'erreurs sont très difficile à reproduire, l'utilisation de mock permet ici de simuler une erreur pour pouvoir traiter ce cas et donc améliorer la couverture de code, par exemple le catch d'une exception ; - sans l'utilisation de mock, le test peut retourner une erreur ne provenant pas du code qui est testé (par exemple une base de données). Cependant, une utilisation abusive de mock peut avoir l'effet inverse, notamment allonger le temps d'exécution des tests, rendre les tests compliqués à comprendre et à maintenir. La plupart des [frameworks](https://fr.wikipedia.org/wiki/Framework "Framework") de la famille [xUnit](https://fr.wikipedia.org/wiki/XUnit "XUnit") permettent la génération des classes de test unitaire. Cependant ces frameworks ne fournissent que le squelette des classes. Les tests devront donc être écrits par le développeur. La génération de tests unitaires est un sujet important pour les chercheurs et plusieurs conférences s'intéressent à cette problématique, telles que [International Symposium on Software Testing and Analysis](https://fr.wikipedia.org/w/index.php?title=International_Symposium_on_Software_Testing_and_Analysis&action=edit&redlink=1 "International Symposium on Software Testing and Analysis (page inexistante)") (ISSTA), [International Conference on Software Engineering](https://fr.wikipedia.org/w/index.php?title=International_Conference_on_Software_Engineering&action=edit&redlink=1 "International Conference on Software Engineering (page inexistante)") (ICSE) et [Automated Software Engineering](https://fr.wikipedia.org/w/index.php?title=Automated_Software_Engineering&action=edit&redlink=1 "Automated Software Engineering (page inexistante)") (ASE). Lors d'une modification dans le code d'un programme, il se peut que certains tests ne passent plus ; dans ce cas, le développeur doit déterminer si cela vient du code en lui-même ou du test : si cela vient du test, le développeur doit modifier son test car la suppression de celui-ci entraînerait une augmentation des chances de régression du programme. Certains chercheurs ont développé des outils pour résoudre ce problème. ReAssert[\[14\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-14) est un outil suggérant des réparations pour un test qui échoue, il analyse les tests à modifier et suggère des changements au développeur, si cette suggestion convient au développeur, il peut effectuer le changement en cliquant sur un bouton. Les tests unitaires paramétrables sont des tests unitaires qui prennent des paramètres. Ils peuvent ensuite utiliser des outils comme QuickCheck pour générer des paramètres. Ces tests sont supportés par [JUnit](https://fr.wikipedia.org/wiki/JUnit "JUnit"), [TestNG](https://fr.wikipedia.org/wiki/TestNG "TestNG") et NUnit. En s'appuyant sur des cas concrets d'entrée et sortie, la génération d'Oracle et sur la couverture de test pour minimiser les cas, des chercheurs ont réussi à générer des tests unitaires paramétrables[\[15\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-15). Les résultats de cette méthode sont prometteurs. Il existe une multitude de cadriciels ([framework](https://fr.wikipedia.org/wiki/Framework "Framework")) permettant de réaliser facilement des tests unitaires. Il en existe dans les principaux [langages de programmation](https://fr.wikipedia.org/wiki/Langage_de_programmation "Langage de programmation"). Par exemple `Test::More`[\[16\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-16) pour le [Perl](https://fr.wikipedia.org/wiki/Langage_Perl "Langage Perl"). Le terme générique « [xUnit](https://fr.wikipedia.org/wiki/XUnit "XUnit") » désigne un outil permettant de réaliser des tests unitaires dans un langage donné (dont l'initiale remplace « x » le plus souvent). - AUnit[\[17\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-17) pour [Ada](https://fr.wikipedia.org/wiki/Ada_\(langage\) "Ada (langage)") ; - ASUnit[\[18\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-18) pour [ActionScript](https://fr.wikipedia.org/wiki/ActionScript "ActionScript") ; - Cppunit[\[19\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-19) pour [C++](https://fr.wikipedia.org/wiki/C%2B%2B "C++") ; - CUnit[\[20\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-20) pour [C](https://fr.wikipedia.org/wiki/C_\(langage\) "C (langage)") ; - DUnit pour [Delphi](https://fr.wikipedia.org/wiki/Embarcadero_Delphi "Embarcadero Delphi") ; - FLEXunit pour [Adobe Flex](https://fr.wikipedia.org/wiki/Adobe_Flex "Adobe Flex") ; - [Google](https://fr.wikipedia.org/wiki/Google "Google") Test[\[21\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-21) et Boost Test[\[22\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-22) pour [C++](https://fr.wikipedia.org/wiki/C%2B%2B "C++") ; - HUnit[\[23\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-23) pour [Haskell](https://fr.wikipedia.org/wiki/Haskell "Haskell") ; - JSUnit[\[24\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-24), QUnit[\[25\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-25), [Unit.js](https://fr.wikipedia.org/wiki/Unit.js "Unit.js")[\[26\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-26) et Jest[\[27\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-27) pour [JavaScript](https://fr.wikipedia.org/wiki/JavaScript "JavaScript") ; - [JUnit](https://fr.wikipedia.org/wiki/JUnit "JUnit")[\[28\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-28) et [TestNG](https://fr.wikipedia.org/wiki/TestNG "TestNG")[\[29\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-29) pour [Java](https://fr.wikipedia.org/wiki/Java_\(langage\) "Java (langage)") ; - NUnit[\[30\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-30) pour [.NET](https://fr.wikipedia.org/wiki/Microsoft_.NET "Microsoft .NET") ; - [Microsoft](https://fr.wikipedia.org/wiki/Microsoft "Microsoft") Unit Test[\[31\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-31) pour [.NET](https://fr.wikipedia.org/wiki/Microsoft_.NET "Microsoft .NET") ; - xUnit[\[32\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-32) pour [.NET](https://fr.wikipedia.org/wiki/Microsoft_.NET "Microsoft .NET") ; - NUnitASP[\[33\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-33) pour [ASP.NET](https://fr.wikipedia.org/wiki/ASP.NET "ASP.NET") (support interrompu depuis le 31 janvier 2008 ) ; - OUnit[\[34\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-34) pour [OCaml](https://fr.wikipedia.org/wiki/OCaml "OCaml") ; - OCunit pour [Objective C](https://fr.wikipedia.org/wiki/Objective_C "Objective C") ; - PBUnit pour [PowerBuilder](https://fr.wikipedia.org/wiki/PowerBuilder "PowerBuilder") ; - [PHPUnit](https://fr.wikipedia.org/wiki/PHPUnit "PHPUnit")[\[35\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-35), SimpleTest[\[36\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-36) et Atoum[\[37\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-37) pour [PHP](https://fr.wikipedia.org/wiki/PHP "PHP") ; - plunit pour [Prolog](https://fr.wikipedia.org/wiki/Prolog "Prolog") ; - utPLSQL[\[38\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-38) pour [PL/SQL](https://fr.wikipedia.org/wiki/PL/SQL "PL/SQL") ; - Unittest et [PyUnit](https://fr.wikipedia.org/wiki/PyUnit "PyUnit") pour [Python](https://fr.wikipedia.org/wiki/Python_\(langage\) "Python (langage)") ; - [Tape](https://fr.wikipedia.org/wiki/Tape_\(framework_de_tests_JavaScript\) "Tape (framework de tests JavaScript)") pour [JavaScript](https://fr.wikipedia.org/wiki/JavaScript "JavaScript") ; - Test::Unit pour [Ruby](https://fr.wikipedia.org/wiki/Ruby "Ruby") ; - Test::More pour [Perl](https://fr.wikipedia.org/wiki/Langage_Perl "Langage Perl") ; - [Typemock](https://fr.wikipedia.org/w/index.php?title=Typemock&action=edit&redlink=1 "Typemock (page inexistante)") pour .NET, C++, C\#. Avec Typemock vous pouvez travailler sur legacy code aussi. - SUnit[\[39\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-39) pour [Smalltalk](https://fr.wikipedia.org/wiki/Smalltalk "Smalltalk") ; - RPGUnit[\[40\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-40) pour RPG ; - ScalaTest pour Scala - SASUnit[\[41\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-41) pour [SAS](https://fr.wikipedia.org/wiki/SAS_\(langage\) "SAS (langage)"). Divers outils permettent l'automatisation des tests unitaires : - Le module TBrun de la suite d'outils [LDRA](https://fr.wikipedia.org/wiki/LDRA "LDRA") ; - Tessy (distribution : Hitex Development Tools/Allemagne). - Ponicode, génération de tests unitaires en Javascript[\[42\]](https://fr.wikipedia.org/wiki/Test_unitaire#cite_note-42). - [Cycle en V](https://fr.wikipedia.org/wiki/Cycle_en_V "Cycle en V") - [Test](https://fr.wikipedia.org/wiki/Test_\(informatique\) "Test (informatique)") - [Extreme programming](https://fr.wikipedia.org/wiki/Extreme_programming "Extreme programming") - [Test Driven Development](https://fr.wikipedia.org/wiki/Test_Driven_Development "Test Driven Development") 1. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-1) (en) Benington, Herbert D., « Production of large computer programs », Proceedings of the Symposium on Advanced Programming Methods for Digital Computers, Washington, D.C., June 28-29, 1956, Office of Naval Research, Department of the Navy,‎ 1956 , p. 15-28 2. ↑ [a](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-:0_2-0) et [b](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-:0_2-1) H. D. Benington, « Production of large computer programs », Proceedings of the 9th international conference on Software Engineering, IEEE Computer Society Press, iCSE '87,‎ 1er mars 1987 , p. 299–310 ([ISBN](https://fr.wikipedia.org/wiki/International_Standard_Book_Number "International Standard Book Number") [978-0-89791-216-7](https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Ouvrages_de_r%C3%A9f%C3%A9rence/978-0-89791-216-7 "Spécial:Ouvrages de référence/978-0-89791-216-7"), [DOI](https://fr.wikipedia.org/wiki/Digital_Object_Identifier "Digital Object Identifier") [10\.5555/41765.41799](https://dx.doi.org/10.5555/41765.41799), [lire en ligne](https://dl.acm.org/doi/10.5555/41765.41799), consulté le 3 avril 2024 ) 3. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-3) Norman A. Zimmerman, « System integration as a programming function », Proceedings of the 1969 24th national conference, Association for Computing Machinery, aCM '69,‎ 26 août 1969 , p. 459–467 ([ISBN](https://fr.wikipedia.org/wiki/International_Standard_Book_Number "International Standard Book Number") [978-1-4503-7493-4](https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Ouvrages_de_r%C3%A9f%C3%A9rence/978-1-4503-7493-4 "Spécial:Ouvrages de référence/978-1-4503-7493-4"), [DOI](https://fr.wikipedia.org/wiki/Digital_Object_Identifier "Digital Object Identifier") [10\.1145/800195.805951](https://dx.doi.org/10.1145/800195.805951), [lire en ligne](https://dl.acm.org/doi/10.1145/800195.805951), consulté le 3 avril 2024 ) 4. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-4) (en) Gouvernement des Etats Unis d'Amérique, Département de la Défence, MIL-STD-483 Military standard: configuration management practices for systems, equipment, munitions, and computer programs , 31 décembre 1970 , Section 3.4.7.2. "The contractor shall then code and test software Units, and enter the source and object code, and associated listings of each successfully tested Unit into the Developmental Configuration" 5. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-5) (en) Michael F. Tighe, « The value of a proper software quality assurance methodology », ACM SIGMETRICS Performance Evaluation Review, vol. 7, nos 3-4,‎ novembre 1978 , p. 165–172 ([ISSN](https://fr.wikipedia.org/wiki/International_Standard_Serial_Number "International Standard Serial Number") [0163-5999](https://portal.issn.org/resource/issn/0163-5999), [DOI](https://fr.wikipedia.org/wiki/Digital_Object_Identifier "Digital Object Identifier") [10\.1145/1007775.811118](https://dx.doi.org/10.1145/1007775.811118), [lire en ligne](https://dl.acm.org/doi/10.1145/1007775.811118), consulté le 3 avril 2024 ) 6. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-6) [Camp Smalltalk SUnit](http://sunit.sourceforge.net/) 7. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-7) [Simple Smalltalk Testing:With Patterns](http://www.xprogramming.com/testfram.htm), in Smalltalk Report octobre 1994, Kent Beck 8. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-8) (en) Ward Cunningham, « [Testing Framework](http://wiki.c2.com/?TestingFramework) » ![Accès libre](https://upload.wikimedia.org/wikipedia/commons/thumb/6/65/Lock-green.svg/20px-Lock-green.svg.png), sur wiki.c2.com . 9. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-9) [Xunit, Martin Fowler](http://www.martinfowler.com/bliki/Xunit.html) 10. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-10) GNU Based Compilation System for Space Embedded Applications, Blondin, J. P. & Martignano, M., DASIA 98 - Data Systems in Aerospace, Proceedings of the conference held 25-28 May, 1998 in Athens, Greece, Edited by B. Kaldeich-Schü.rmann. ESA SP-422. Paris: European Space Agency, 1998., p.137, "1998ESASP.422..137B", page 138 <http://adsbit.harvard.edu//full/1998ESASP.422..137B/0000138.000.html> 11. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-11) [Unit Testing Best Practices, Roy Osherove](https://fr.wikipedia.org/wiki/Programmation_informatique "Programmation informatique"). 12. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-12) [Test First, bob Martin](http://blog.8thlight.com/uncle-bob/2013/09/23/Test-first.html). 13. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-13) Robert Martin, When to Mock. 14. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-14) (en) Brett Daniel, Danny Dig, Tihomir Gvero, Vilas Jagannath, Johnston Jiaa, Damion Mitchell, Jurand Nogiec, Shin Hwei Tan et Darko Marinov, « ReAssert: a tool for repairing broken unit tests », ICSE,‎ 2011 ([lire en ligne](http://dl.acm.org/citation.cfm?doid=1985793.1985978)) . 15. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-15) (en) Gordon Fraser et Andreas Zeller, « Generating Parameterized Unit Tests », ISSTA,‎ 2011 ([lire en ligne](http://dl.acm.org/citation.cfm?doid=2001420.2001464)) . 16. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-16) [Test::More sur CPAN](https://metacpan.org/module/Test::More), entre autres [modules de tests](https://metacpan.org/search?q=Test). Voir aussi les articles de l'association des mongueurs de Perl dans [Linux Magazine France](https://fr.wikipedia.org/wiki/Linux_Magazine_France "Linux Magazine France") disponibles sur <http://articles.mongueurs.net/magazines> 17. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-17) [AUnit](https://libre.adacore.com/aunit/main.html) 18. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-18) [AsUnit](http://www.asunit.org/) 19. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-19) [CppUnit](http://cppunit.sourceforge.net/) et en [version 2](https://launchpad.net/cppunit2) 20. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-20) [CUnit](http://cunit.sourceforge.net/) 21. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-21) [GoogleTest](https://code.google.com/p/googletest/) 22. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-22) [Boost.Test](http://www.boost.org/doc/libs/release/libs/test/index.html) 23. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-23) [HUnit](http://hunit.sourceforge.net/) 24. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-24) [JsUnit](http://www.jsunit.net/) 25. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-25) [http://qunitjs.com](http://qunitjs.com/) Unit testing for Javascript made by the jQuery Foundation 26. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-26) (en) [Unit JS](http://unitjs.com/) : « Unit testing framework for Javascript ». 27. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-27) (en) « [Jest · 🃏 Delightful JavaScript Testing](https://jestjs.io/) », sur jestjs.io (consulté le 2 mars 2020 ) . 28. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-28) [Welcome to The New JUnit.org! \\| JUnit.org](http://junit.org/). 29. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-29) (en) « [TestNG Documentation](http://testng.org/) », sur testng.org (consulté le 21 mai 2024 ) . 30. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-30) [NUnit - Home](http://www.nunit.org/) 31. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-31) (en-US) erickson-doug, « [Writing Unit Tests for the .NET Framework with the Microsoft Unit Test Framework for Managed Code - Visual Studio](https://docs.microsoft.com/fr-fr/visualstudio/test/writing-unit-tests-for-the-dotnet-framework-with-the-microsoft-unit-test-framework-for-managed-code?view=vs-2015) », sur docs.microsoft.com (consulté le 4 septembre 2018 ) . 32. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-32) (en) « [Home \> xUnit.net](https://xunit.github.io/) », sur xunit.github.io (consulté le 4 septembre 2018 ) . 33. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-33) [NUnitAsp - ASP.NET unit testing](http://nunitasp.sourceforge.net/) 34. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-34) [OUnit](http://ounit.forge.ocamlcore.org/) 35. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-35) [PHPUnit - Trac](https://www.phpunit.de/) 36. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-36) [SimpleTest - Unit Testing for PHP](http://www.simpletest.org/) 37. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-37) [Atoum](http://www.atoum.org/) 38. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-38) [utPLSQL](http://utplsql.sourceforge.net/) 39. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-39) [Simple Smalltalk Testing: With Patterns](http://www.xprogramming.com/testfram.htm) 40. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-40) <http://rpgunit.sourceforge.net/> 41. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-41) (en) « [SASUnit](https://sourceforge.net/projects/sasunit/) », sur SourceForge (consulté le 24 février 2020 ) . 42. [↑](https://fr.wikipedia.org/wiki/Test_unitaire#cite_ref-42) (en) « [Ponicode - Quick and easy Javascript unit testing](https://ponicode.com/) », sur ponicode.com (consulté le 23 juin 2020 ) . \| [v](https://fr.wikipedia.org/wiki/Mod%C3%A8le:Palette_Qualit%C3%A9_logicielle "Modèle:Palette Qualité logicielle") · [m](https://fr.wikipedia.org/w/index.php?title=Mod%C3%A8le:Palette_Qualit%C3%A9_logicielle&action=edit)Gestion de la [qualité logicielle](https://fr.wikipedia.org/wiki/Qualit%C3%A9_logicielle "Qualité logicielle") \| \| \|---\|---\| \| [Indicateurs de qualité](https://fr.wikipedia.org/wiki/Qualit%C3%A9_logicielle#Indicateurs_de_qualit%C3%A9_logicielle "Qualité logicielle") ([ISO/CEI 9126](https://fr.wikipedia.org/wiki/ISO/CEI_9126 "ISO/CEI 9126")) \| Capacité fonctionnelle (réponse aux [exigences](https://fr.wikipedia.org/wiki/Exigence_\(ing%C3%A9nierie\) "Exigence (ingénierie)")) [Fiabilité](https://fr.wikipedia.org/wiki/Fiabilit%C3%A9 "Fiabilité") [Maintenabilité](https://fr.wikipedia.org/wiki/Maintenabilit%C3%A9 "Maintenabilité") [Performance](https://fr.wikipedia.org/wiki/Performances_\(informatique\) "Performances (informatique)") [Portabilité](https://fr.wikipedia.org/wiki/Portabilit%C3%A9_\(informatique\) "Portabilité (informatique)") [Utilisabilité](https://fr.wikipedia.org/wiki/Utilisabilit%C3%A9 "Utilisabilité") \| \| Compréhension et contrôle du [code source](https://fr.wikipedia.org/wiki/Code_source "Code source") \| \| \| \| \| \| [Tests](https://fr.wikipedia.org/wiki/Test_\(informatique\) "Test (informatique)") \| [Acceptation](https://fr.wikipedia.org/wiki/Test_d%27acceptation "Test d'acceptation") [Intégration](https://fr.wikipedia.org/wiki/Test_d%27int%C3%A9gration "Test d'intégration") [Performance](https://fr.wikipedia.org/wiki/Test_de_performance "Test de performance") [Régression](https://fr.wikipedia.org/wiki/Test_de_r%C3%A9gression "Test de régression") [Unitaire]() [Utilisateur](https://fr.wikipedia.org/wiki/Test_utilisateur "Test utilisateur") [Validation](https://fr.wikipedia.org/wiki/Test_de_validation "Test de validation") \| \| [Métriques](https://fr.wikipedia.org/wiki/M%C3%A9trique_\(logiciel\) "Métrique (logiciel)") \| [Cohésion](https://fr.wikipedia.org/wiki/Coh%C3%A9sion_\(informatique\) "Cohésion (informatique)") [Couplage](https://fr.wikipedia.org/wiki/Couplage_\(informatique\) "Couplage (informatique)") [Couverture de code](https://fr.wikipedia.org/wiki/Couverture_de_code "Couverture de code") [Halstead](https://fr.wikipedia.org/wiki/M%C3%A9triques_d%27Halstead "Métriques d'Halstead") [Indépendance fonctionnelle](https://fr.wikipedia.org/wiki/Ind%C3%A9pendance_fonctionnelle "Indépendance fonctionnelle") [Indice de maintenabilité](https://fr.wikipedia.org/wiki/Indice_de_maintenabilit%C3%A9 "Indice de maintenabilité") [Ligne de code](https://fr.wikipedia.org/wiki/Ligne_de_code "Ligne de code") [Nombre cyclomatique](https://fr.wikipedia.org/wiki/Nombre_cyclomatique "Nombre cyclomatique") [Point de fonction](https://fr.wikipedia.org/wiki/Point_de_fonction "Point de fonction") \| \| Remaniements \| [Maintenance](https://fr.wikipedia.org/wiki/Maintenance_du_logiciel "Maintenance du logiciel") [Optimisation de code](https://fr.wikipedia.org/wiki/Optimisation_de_code "Optimisation de code") [Réusinage de code](https://fr.wikipedia.org/wiki/R%C3%A9usinage_de_code "Réusinage de code") ([Règle de trois](https://fr.wikipedia.org/wiki/R%C3%A8gle_de_trois_\(programmation_informatique\) "Règle de trois (programmation informatique)")) \| \| Principes de [programmation](https://fr.wikipedia.org/wiki/Programmation_informatique "Programmation informatique") \| \| \| \| \| \| [SOLID](https://fr.wikipedia.org/wiki/SOLID_\(informatique\) "SOLID (informatique)") \| [Responsabilité unique](https://fr.wikipedia.org/wiki/Principe_de_responsabilit%C3%A9_unique "Principe de responsabilité unique") [Ouvert/fermé](https://fr.wikipedia.org/wiki/Principe_ouvert/ferm%C3%A9 "Principe ouvert/fermé") [Substitution de Liskov](https://fr.wikipedia.org/wiki/Principe_de_substitution_de_Liskov "Principe de substitution de Liskov") [Ségrégation des interfaces](https://fr.wikipedia.org/wiki/Principe_de_s%C3%A9gr%C3%A9gation_des_interfaces "Principe de ségrégation des interfaces") [Inversion des dépendances](https://fr.wikipedia.org/wiki/Inversion_des_d%C3%A9pendances "Inversion des dépendances") \| \| Mauvaises pratiques \| \| \| \| \| \| [Antipatterns](https://fr.wikipedia.org/wiki/Antipattern "Antipattern") \| [Attente active](https://fr.wikipedia.org/wiki/Attente_active "Attente active") [Grosse boule de boue](https://fr.wikipedia.org/wiki/Grosse_boule_de_boue "Grosse boule de boue") [Programmation spaghetti](https://fr.wikipedia.org/wiki/Programmation_spaghetti "Programmation spaghetti") ([syndrome](https://fr.wikipedia.org/wiki/Syndrome_du_plat_de_spaghettis "Syndrome du plat de spaghettis")) [Réinventer la roue](https://fr.wikipedia.org/wiki/R%C3%A9inventer_la_roue "Réinventer la roue") \| \| \| \| \| [Code smells](https://fr.wikipedia.org/wiki/Code_smell "Code smell") \| [Duplication de code](https://fr.wikipedia.org/wiki/Duplication_de_code "Duplication de code") [God object](https://fr.wikipedia.org/wiki/God_object "God object") \| \| Voir aussi : [Génie logiciel](https://fr.wikipedia.org/wiki/G%C3%A9nie_logiciel "Génie logiciel"), [Software craftsmanship](https://fr.wikipedia.org/wiki/Software_craftsmanship "Software craftsmanship"), [Dégradation logicielle](https://fr.wikipedia.org/wiki/D%C3%A9gradation_logicielle "Dégradation logicielle") \| \| - [![icône décorative](https://upload.wikimedia.org/wikipedia/commons/thumb/0/02/Circle-icons-computer.svg/40px-Circle-icons-computer.svg.png)](https://fr.wikipedia.org/wiki/Portail:Informatique "Portail de l’informatique") [Portail de l’informatique](https://fr.wikipedia.org/wiki/Portail:Informatique "Portail:Informatique")
Shard	152 (laksa)
Root Hash	17790707453426894952
Unparsed URL	org,wikipedia!fr,/wiki/Test_unitaire s443