tests unitaires - club d'entraide des développeurs francophones

tests unitaires - club d'entraide des développeurs francophones rechercher: sur developpez.com sur les forums forums | tutoriels | f.a.q's | participez | hébergement | contacts club blogs emploi formation dév. web php xml python autres 2d-3d-jeux sécurité systèmes windows linux accueil   tv   conception java dotnet visual basic  c  c++ delphi pascal ms-office sql & sgbd oracle  4d  forums java faqs java tutoriels java javasearch sources java livres java outils, edi & api blog java java tv trucs et astuces validité des paramètres documenter votre code assertions tests unitaires design patterns - gof adaptateur composite décorateur etat façade kit monteur pont proxy singleton design patterns - avalon ioc - inversion of control soc - seperation of concerns cop - component orientated programming sop - service orientated programming autres articles cahier xml sax en java fractal aspectj voir aussi patterns du grasp héritage avec des ejb entiy cmp ressouces java informations cours livres faq outils edi ressources uml cours livres forums d'entraide géneral java j2ee jbuilder outils edi méthodes/uml/mérise tests unitaires 15 janvier 2003 modifié le 4 octobre 2003 version 1.1 par sébastien meric remerciements : johann heymes, stefan bertholon, laurent petit l'utilisation de framework de tests unitaires est essentielle à la constitution d'un code robuste. elle s'inscrit dans la lignée des articles précédents et viens en complément, vous aider, d'une part à placer votre code en situation difficile, d'autre part, elle en améliore la lisibilité ! est-ce possible, alors qu'on écrit plus de code que necessaire ? n'allez-vous pas passer encore du temps à écrire du code en plus de ce qui est demandé, déjà qu'il y a les commentaires à écrire. nous verrons que loin de ralentir le développement, il vous fait gagner un temps de débuggage franchement important. sachant qu'avant d'avoir mis au point ces diverses techniques, le débuggage était considéré comme occupant une part allant de 50% du temps pour un expert à 90% pour un débutant, je vous laisse imaginer le gain en performances que vous allez faire. introduction comme pour chaque article de cette série, les exemples sont en java mais le concept vaut pour tous les langages (au moins objets). dans cet article particulier, je vous décris l'utilisation d'un framework particulier : junit. les concepts restent toutefois les mêmes pour d'autres frameworks, et les bonnes et mauvaises pratiques du chapitre utilisation s'appliquent probablement aussi la plupart du temps. par ailleurs,pour vous permettre de travailler, je vous donne les urls de téléchargement du framework, pour java, c++, delphi et .net. pour avoir déjà utilisé le framework de delphi, je peux vous dire qu'il n'est pas rigoureusement équivalent à celui de java, mais que l'adaptation du code java en pascal est vraiment simple. les voici donc : javajunit c++cunit delphidunit .netnunit avant propos le terme framework est régulièrement utilisé dans ce document, je me permet donc d'en proposer une traduction/définition : un framework est une infrastructure logicielle qui facilite la conception des applications par l'utilisation de bibliothèques de classes ou de générateurs de programmes, soit dit en quelques mots : un cadre de développement. concepts quand ? quand doit-on écrire des tests, c'est à dire à quelle phase du développement doit-on s'y mettre ? sur ce point, l'une des pratiques les plus en vogue aujourd'hui, l'extreme programming, nous dit de les écrire avant même de commencer à coder. certains pratiquent aussi le pair programming (programmation en binôme) de la manière suivante : discussion du binôme autour de développement à effectuer (on ne parle pas des 5 jours à venir mais des 30 minutes à venir) puis chacun retourne à sa machine et l'un des développeurs écrit les tests, tandis que l'autre implémente. quoi qu'il en soit, les tests s'écrivent en même temps que le code. légèrement avant, légèrement après ou exactement en même temps ? peu importe votre méthode, mais vous ne devez pas écrire tous les tests d'un coup avant le développement, ni les écrire après avoir terminé l'implémentation (ce serait totalement inutile). pour ma part, j'opte plutôt pour l'écriture des tests avant le code ; en effet, cette pratique a plusieurs avantages : affiner l'analyse, en particulier, si en écrivant le javadoc avant le code, vous avez recensé les besoins, ici vous recensez les cas d'utilisations, apporter l'ensemble des règles pré et postconditions traitées dans l'article sur les assertions, apporter aussi l'ensemble des traitements de vérification de paramètres également traités dans un article précédent, eviter d'écrire du code inutile. en effet, si vos tests (bien écris s'entend) passent tous, inutile d'ajouter du code à votre classe. donc vous implémentez jusqu'à ce que tous les tests passent, puis vous arrêtez et passez au point suivant. documenter ! ne vous méprenez pas sur ce titre, il ne s'agit pas de documenter le test, mais de s'en servir comme d'une documentation technique. en effet, l'utilisation de vos classes est toujours difficile à documenter. qui plus est, une documentation à part risque fort d'être rapidement désuète. ceci vous décourage dans l'écriture d'une documentation et vous mène souvent à la rédaction de celle-ci en fin de projet, soit beaucoup trop tard. le test est en lui-même un exemple d'utilisation et de manipulation de vos classes, il vous permet donc de documenter celles-ci. donc, en plus d'ajouter de la valeur logicielle, le test apporte de la valeur documentaire à vos codes, vous hésitez encore à en écrire ? une simulation d'ihm développée en quelques minutes si vous partez d'un code qui fonctionne, que vous lui ajoutez un peu de fonctionnel, où se trouve le bug ? dans les lignes que vous avez ajouté bien entendu ! donc plus vous testez régulièrement, plus le bug est facilement détectable. et oui, dénicher un bug dans 2 ou 3 lignes de code regroupées est beaucoup plus simple que de le detecter dans une trentaine de lignes réparties sur plusieurs classes ! alors le problème c'est qu'aujourd'hui, vous êtes obligé d'écrire, le code métier, le code de persistance et le code de l'ihm avant de pouvoir vraiment tester quoi que ce soit. le framework de test vous apporte donc une solution sur mesure pour résoudre ce problème : il faut quelques lignes seulement pour écrire le client graphique (même s'il ne se présente pas franchement comme l'ihm définitive). vous vous affranchissez donc de deux problèmes en une seule fois : ne pas être obligé de coder l'interface graphique tant que le métier n'est pas implémenté, et ne pas dépendre du débugage de l'ihm elle-même pendant le codage du métier. toujours des hésitations ? quelques secondes pour mettre toute votre application à l'épreuve une fois les tests écrits, il suffit de quelques secondes pour les lancer, et obtenir un compte-rendu. et vous obtenez en quelques secondes, ou quelques minutes si votre application est vraiment importante et que vous lancez vraiment absolument tous les tests, un compte-rendu exhaustif de ce qui marche et de ce qui ne marche pas ! avez-vous déjà pris le temps de tester une application de manière exhaustive ? c'est pourtant ce qu'il faut faire avant de la livrer, et ce qu'il faudrait faire à chaque modification. autant dire que même pour une application de petite taille, si vous la testez manuellement, ça vous prendra au bas mot plusieurs dizaines de minutes ! vous ne le faites donc que rarement et ça vous est préjudiciable, vous allez encore passer des heures à débugger un petit rien simplement parce qu'au moment où vous avez généré le bug, vous n'avez pas tout testé ! si vous n'êtes toujours pas convaincu par le fait qu'il faut écrire des tests, j'ai encore un paragraphe pour vous faire changer d'avis, mais vous êtes un peu dur ;-) non régression combien de fois ai-je entendu "je ne comprends pas pourquoi, hier ça marchait ! " ? impossible de repondre... trop souvent en tout cas. le pire, etant certainement de l'avoir entendu sortir de sa propre bouche... vous ne voulez plus vous entendre dire à votre responsable que hier ça marchait, ou vous ne voulez plus entendre vos collègues vous dire ce genre de lieu commun des développeurs. de plus, afin que la maintenance de votre code puisse être éffectuée par tous, sans pour autant que de nouveaux bugs soient introduits par un tiers, il faut lever un drapeau "attention, ne marche pas comme prévu ! ". les tests unitaires sont là pour ça. la non régression du code, c'est donc, la certitude que l'on avance. c'est aussi la confiance qui s'installe : "je peux modifier mon code puisqu'il résiste au pire, je saurais immédiatement s'il y a bug, où et pourquoi". et la confiance en soi donne la force d'avancer plus vite. alors, perdre son temps à écrire quelques tests, c'est gagner des heures de débug (ce qui vous intéresse le moins dans votre métier j'en suis certain), ça n'est donc pas utile, mais essentiel. dans quelques semaines, après avoir acquis suffisamment de réflexes pour l'écriture de ces tests, vous repenserez à cette période ancestrale durant laquelle vous écriviez du code sans écrire de tests, et vous vous demanderez alors comment vous faisiez. utilisation ecrire une série de tests pour une classe commençons par observer la syntaxe à respecter pour écrire un test, ensuite, nous verrons comment réunir plusieurs séries de tests pour un lancement simultané. enfin, une fois que l'on sera capable d'écrire les tests, on essayera de débrouiller les situations pour lesquelles écrire les tests et dans quelles conditions les écrire. une classe héritant de junit.framework.testcase pour commencer, c'est le socle de votre série. dans cette classe, vous pouvez définir les séries de tests tout simplement en déclarant des méthodes publiques dont le nom commence par les quatres lettres (en minuscules) test. voilà, vous avez défini un testcase que vous pouvez passer en paramètre à un testrunner pour lancer vos tests. c'est simple non ? bien entendu, il reste encore à comprendre ce qu'il faut mettre dans les méthodes testxxx(). vous n'allez pas être dépaysé si vous avez déjà lu l'article sur les assertions, car les tests se font justement à coup d'assertions. voilà un exemple de test, je mets une méthode main() dans la classe afin de la rendre exécutable, il n'y a rien d'obligatoire à ça bien entendu. 1 package com.developpez.tutoriels.astuces.tests; 2 3 /** 4 * classe de test pour une pseudo classe de traitement d'une facture 5 */ 6 7 public class testfacture extends junit.framework.testcase { 8 public void main(string[] args) { 9 // pas de vérification des paramètres, ce n'est pas l'objet 10 junit.textui.testrunner.run(testfacture.class);11 }12 13 public testfacture(string name) {14 // ce constructeur est obligatoire car il n'existe pas 15 // de constructeur par defaut dans les testcase 16 super(name);17 }18 19 public void testajoutarticles() {20 facture mafacture = new facture();21 mafacture.add(new article("article 1", 3, 150.0));22 mafacture.add(new article("article 2", 1, 50.0));23 24 assertnotnull("la facture ne devrait pas être null", mafacture);25 assertequals("le total de la facture est mal calculé",26 3 * 150 + 50, 0.0001,27 mafacture.gettotal());28 assertequals("le nombre d'articles est mal calculé",29 4,30 mafacture.countarticles());31 }32 public void testvalidationfacture() {33 facture mafacture = new facture();34 mafacture.add(new article("article 1", 3, 150.0));35 mafacture.add(new article("article 2", 1, 50.0));36 mafacture.valide();37 38 asserttrue("la validation de la facture n'a pas eu lieu",39 mafacture.isvalide());40 41 try {42 mafacture.add(new article("article 3", 1, 20.20));43 fail("facture modifiée après validation");44 } catch (factureexception e) {45 // interdit de modifier une facture valide donc 46 // c'est normal d'être ici 47 48 }49 }50 } a remarquer tout de suite dans ce code : j'utilise le testrunner en mode texte, je le trouve plus pratique car il envoie tout sur la sortie standard ou erreur et en général votre ide permet de vous diriger directement vers le code incriminé en cas d'erreur. il existe toutefois un testrunner awt et un swing qui présente les résultats de manière plus graphique. a vous de choisir. je vous indique quelques méthodes assertxxx, il en existe beaucoup, leur nom est suffisamment parlant pour que je ne vous fasse pas un glossaire exhaustif. l'assertion sur l'égalité de réels se fait à l'aide de trois réels, les deux réels à comparer, et une approximation. les assertions d'égalités vous livrent comme message "value" expected but "value" found. un message (string) peut être spécifié pour toutes les assertions, il sera livré si elles ne sont pas vérifiées. enfin, le nom des méthodes testxxxx sera repris dans les messages, veillez à ce qu'il signifie quelque chose. réunir les tests en une suite de tests comme lancer un test pour une classe est loin de tester l'application complète, il est possible de réunir les tests dans des faisceaux de tests, les testsuite. ensuite, leur lancement se fait de la même manière qu'avec un testcase, . bien entendu, vous pouvez réunir plusieurs testsuite dans un testsuite plus important, etc. jusqu'à obtenir un test de l'application complète. ceci est avantageux sur une application pour laquelle les tests peuvent prendre plusieurs minutes, en effet, l'intéret des tests est de pouvoir les lancer presque toutes les 5 minutes afin de détecter très tôt les bugs. bonnes pratiques une classe, un test une classe devant être testée, autant qu'elle dispose de son propre module de tests. comme la notion de module de granularité la plus fine en java est la classe, on écrit une classe de test pour chaque classe à tester.  cela vous permet de retrouver facilement le test attaché à une classe ; pour ce faire, il suffit de prendre la convention de nommage : testmaclass et le tour est joué. tests dans le même package que la classe à tester cette résolution est simple à expliquer. si vous voulez pouvoir tester l'intérieur d'un composant (classe déclarée de visibilité niveau package ou méthodes déclarées de visibilité niveau package), il vous faut écrire la classe de tests dans le même  package. par ailleurs, pour retrouver la classe de tests spécifique d'une classe, il est plus facile de la chercher dans le même package. enfin, si deux classes portent le même nom mais se trouvent dans des packages différents, autant que les classes de tests se trouvent aussi dans des packages différents. scénarii ecrire les scénarii courants vous avez maintenant écrit les assertions pour vous assurer de la véracité de ce que vous supposiez avoir écrit. a présent, il vous reste à écrire les scénarii d'utilisation courante de votre classe. en effet, c'est déjà important que ce qui est attendu fonctionne, mais les méthodes s'appellent généralement suivant des enchaînements logiques, qui doivent aboutir à une réalisation donnée,  autant s'en assurer. et surtout mettre l'application en difficulté ecrire les scénarii catastrophe pour vérifier que l'application résiste bien. que l'utilisateur à une bonne chance de recevoir un message clair dans ce type de cas. bref, faire faire par vos testcase le test du client qui s'assied sur le clavier. mauvaises pratiques ne pas mettre les classes dans le même répertoire que les tests en effet, évitez de mettre ensemble les sources des tests avec celles de l'application car il est plutôt probable que vous n'aillez pas envie, en particulier parce que ce n'est pas judicieux, de livrer et déployer votre application avec les tests. pour pouvoir gérer aisément la fabrication des jars et la compilation, il est donc préférable de séparer les sources. ne  pas écrire de tests triviaux ecrire des tests triviaux revient à perdre du temps : c'est inutile. ca donne l'impression que l'écriture de tests fait perdre du temps : c'est fallacieux. malheureusement il est plus facile de dire n'écrivez pas de tests triviaux que de déterminer la trivialité ou non d'un test. comme précisé dans la rubrique précédente, pour être certain d'avoir écrit des tests, si possible non triviaux, le mieux est de commencer par écrire les scénarii attendus, et les scénarii catastrophe. vous obtenez déjà un bon point de départ. ensuite, ajoutez tous les invariants de classe si vous n'utilisez pas déjà un framework de programmation par contrat comme expliqué dans l'article sur l'utilisation des assertions pas d'effet de bord dans les tests vos tests doivent pouvoir tourner 100, 200, 1000 fois et plus encore... si l'un de vos tests provoque des effets de bord sur l'état de votre système, vous aurez alors des tests qui ne se vérifient qu'une seule et unique fois. vous devez donc absolument éviter les effets de bord dans vos tests. ne présumer pas de l'ordre dans lequel les tests sont lancés en particulier, ne présumez pas de l'ordre dans lequel sera lancé vos tests. en effet, le framework utilise l'introspection (java.lang.reflect) mais vous n'avez aucune idée de la manière dont la jvm implémente cette introspection, est-ce qu'elle prend les méthodes dans l'ordre d'implémentation ? dans le sens inverse à cause d'une pile (j'empile, je désempile) ? ou par ordre alphabétique (pourquoi pas ?) ?etc... vous ne pouvez donc pas écrire des tests du type testinsert testmodif testsupprime ou test insert insert l'enregistrement que testmodif modifie et que testsupprime supprime. il faut donc tester un scénario complet, de la création à la suppression en passant par la modification. ne laisser pas, surtout dans les couches de persistances, d'effets de bords pensez aussi à laisser le système précisément dans l'état dans lequel il se trouvait avant que les tests ne soient lancés, surtout pour toute la partie persistante. en effet, imaginez que vous écriviez un test d'insertion de société dans votre système, mais que vous ne pensiez pas à supprimer cette société de la base de données sur laquelle votre système repose. que se passera-t-il au deuxième lancement de vos tests, sachant que l'une des contraintes sur les sociétés, est l'unicité de raison sociale ? et oui, le test d'insertion échoue alors que tout se passe à merveille puisque même la contrainte est traitée. donc le test ne fonctionne qu'une fois, autant dire que c'est inutile ! conclusion en résumé, écrire des tests permet une analyse de petite granularité la certitude d'engendrer peu de bugs la non régréssion du code la documentation efficace de votre code l'écriture des tests n'est pas difficile et n'est pas longue non plus (à condition d'être pratiquée au fur et a mesure du développement). pour comble, apprendre à coder son premier test ne prend que 10 minutes. et même si pour apprendre à écrire efficacement ses tests, il faut de la pratique, en écrire "peu efficacement" reste plus efficace que de ne pas en écrire du tout. j'ai beau essayer d'explorer ce qui pourrait nous pousser à ne pas en écrire, je ne trouve rien de probant. il ne reste donc qu'une conclusion possible : dès demain... tut tut tut... non dès tout de suite un clic sur le lien qui correspond à votre environnement de travail pour un download immédiat.     modifications entre la version 1.0 et 1.1 : corrections de bugs dans le code exemple en java. ligne 25 et 28 l'assertequals() s'écrit assertequals(message en cas d'échec, valeur attendue, valeur trouvée) ligne 38 assertxxx s'écrit toujours avec le message comme premier paramètre si un message est fourni. ligne 48 déplacée en 43 et suppression du return pour permettre de lancer d'autres tests à la suite de celui-ci. copyright (c) 2003 sébastien meric. permission is granted to copy, distribute and/or modify this document under the terms of the gnu free documentation license, version 1.1 or any later version published by the free software foundation; with no invariant sections, with the front-cover texts being tests unitaires, and back-cover texts being ce document à été écrit pour la communauté de développeurs francophones "www.developpez.com". a copy of the license is included in the section entitled "gnu free documentation license". /java/astuces/tests   responsables bénévoles de la rubrique java : christophe jollivet et eric siber - contacter par email : vos questions techniques : forum d'entraide java - publiez vos articles, tutoriels et cours et rejoignez-nous dans l'équipe de rédaction du club d'entraide des développeurs francophones nous contacter - copyright © 2000-2007 www.developpez.com - legal informations. mesure d'audience roi frequentation par

Acceuil

suivante

tests unitaires - club d'entraide des développeurs francophones  Immigration : visa contre test ADN, la nouvelle règle française ...  Tests unitaires et doublures de tests : les simulacres ne sont pas ...  Les tests unitaires en JavaScript - JDN Développeurs  Renaud Feil (HSC) : "Notre formation aux tests d'intrusion fournit ...  Tests et diplômes -Ministère des Affaires étrangères-  8800 GT tests & infos  TEST QI GRATUIT, tests de qi et tests en ligne gratuits  Votre santé et vous - Tests médicaux à domicile  NerdTests.com Fun Tests - Nerd Quiz  Les tests d'instruments d'astronomie de Ciel & Espace - Ciel & Espace  IQ test, beroepskeuzetest, beroepentest, online assessement testen ...  Tests humour et Quizz en ligne  Tests ADN: François Bayrou est prêt à signer avec la Gauche le ...  Le Monde.fr : Des tests génétiques pour le regroupement familial  Certif Express - Passage de tests blancs de Certification gratuitement  Humour : 2 tests dvd  Dvd - tous les derniers tests sur dvdrama.com  Tests - Quotient intellectuel (QI) - Yahoo! Jeux  Tests - Quotient sexuel (QX) - Yahoo! Jeux  Tests : 3 lecteurs Creative, Zen, Zen Stone, Zen Vision W - Les ...  Tests, Examens et Cours multimédias de code de la route en ligne ...  Jeux video, soluces, trainers, programmes gratuits, tests ...  Réseau Education Sans Frontières - The Guardian / English tests ...  Tests, Formation continue, formation professionnelle et formation ...  PC-TESTS :: Forum informatique - Accueil  FAQ : Tests génétiques  tests de personnalité gratuits, test gratuit et original de ...  Les Tests - Tests  Quizako.com création et publication gratuite de quiz, tests, et ...  IQ Tests  Tests électroniques, interfaces de tests, test électronique pour ...  Tests appareils photos numériques Zone Numérique  Mac OS X Leopard : sortie, tests et mises à jour  Thot / Tests de santé : cœur, énergie, activité physique, masse ...  Yahoo! Jeux - Tests (QI, Q.I., Quotient intellectuel)  Antivols vélos : conseils et tests de la FUBicy.  References.be: Tests interactifs  Tests Psychotechniques infirmiers tests psy test psycho IFSI  JeuxActu.com - jeu video, actualité tests previews hardware ...  Des chercheurs s’élèvent contre les tests ADN  Tests cosmétiques, Botox, produits cosmétiques et d’entretien sans ...  Tableaux des tests  Design-up::Les tests unitaires  Listes des tests Playstation 2 sur JeuxVideo.com  Tests Produits  Monster tests  Testez vos connaissances QCM QI IQ  Psycho et Tests  Cours et tests de langue en France  About unit tests - jd:/dev/blog  ๑ Test QI - Test de personnalité  Des vidéos, des tests et toute l'actualité Xbox 360 des sites ...  Le Rucher.com  Code de la route : le plus grand site du code de la route en ligne  Tests  TESTS PSYCHOTECHNIQUES : Plus de 50 tests en ligne.  Tests online - ESL séjours linguistiques  Tests matériels SVM  Clear Choice Tests  Realiza Tests online. Test de amor. Test de inteligencia. Test de ...