Bases de la conception orientée objet M2104

Transcription

1 Bases de la conception orientée objet M2104 DUT Informatique 2 e semestre Eric REMY eric.remy@univ-amu.fr IUT d Aix-Marseille, site d Arles Version du 5 juin 2015 E. Remy (IUT d Arles) M / 37

2 Introduction Au delà de la conception «orientée objet» elle-même, on va s intéresser ensemble à des outils de développement : des outils de travail collaboratif spécifiques pour la programmation ; des outils liés à la qualité du code produit, sous deux aspects : la qualité des commentaires destinés à sa maintenance ; le contrôle du respect des fonctionnalités attendues (les «tests unitaires») ; les méthodes les plus courantes de gestion de projet : le «cycle en V» classique ; les méthodes agiles (par exemple, extreme programming) ; le développement guidé par les tests. Un développeur moderne ne peut pas faire l impasse sur ce type d outils : même s ils sont variés, vous devez les connaître, et autant que possible les maîtriser afin de vous intégrer au mieux dans les entreprises où vous irez. E. Remy (IUT d Arles) M / 37

3 Première partie Travail collaboratif E. Remy (IUT d Arles) M / 37

4 Travail collaboratif Les techniques actuelles de développement logiciels privilégient la conception «orientée objet» car cela permet : de découper le travail en tâches bien identifiées ; et donc de se les répartir au sein d un groupe de développeurs. Mais la technique de conception ne résout pas pour autant certains problèmes pratiques lors de la réalisation comme par exemple : Comment stocker les différentes versions des fichiers sources d un projet commun? Comment se les échanger en minimisant les erreurs humaines? Comment réduire le risque de perdre des données? Comment garder efficacement un historique des versions au cours du temps? Comment améliorer la communication des membres au sujet du projet?... Comment vous y prendriez-vous? E. Remy (IUT d Arles) M / 37

5 Des logiciels pour le travail collaboratif On peut citer plusieurs catégories de logiciels de travail collaboratif de développement : les stockages dans les «nuages» (cloud) (Google Drive, Drop Box, owncloud, etc.) : ne répondent pratiquement pas aux critères cités précédemment, et ne sont pas du tout spécialisés pour le développement! les systèmes de gestion de versions (Version Control System) : RCS (archaïque), CVS, Subversion, Git, Bazaar, Mercurial, etc. les «forges» qui étendent un des systèmes de gestion de version précédents avec des services supplémentaires Web (flux RSS, messagerie, Wiki, forum, suivi de bogues, outils de pilotage du travail d équipe, etc.) : GitHub, Sourceforge.net (TeamForge), etc. On va apprendre ensemble les bases de l utilisation de Subversion. Si vous comprenez les grands principes de celui-là, vous pourrez apprendre les autres sans (trop de) difficulté. E. Remy (IUT d Arles) M / 37

6 Subversion Présentation Logiciel libre (sous licence Apache) Site Web officiel Serveur centralisé (contrairement à git qui est décentralisé) Toujours très utilisé même si moins à la mode que git Dispose d un greffon pour Microsoft Windows : TortoiseSVN La majorité des Environnement de développement intégrés ont des greffons pour l utiliser aussi... mais dans un souci de simplicité, nous l utiliserons en ligne de commande. E. Remy (IUT d Arles) M / 37

7 Vocabulaire (1/2) Vous devrez vous habituer à certains concepts qui se cachent derrière des mots précis : Dépôt (repository) : le serveur + répertoire qui stocke toutes les versions successives du travail commun Copie de travail (working copy) : votre copie locale du dépôt, sur laquelle vous travaillez commit : la transaction consistant à transmettre l intégralité des modifications d une copie de travail locale vers le dépôt central Revision : le numéro unique de version attribué par le serveur à l issue d un commit Mise à jour (update) : la récupération vers la copie de travail locale des changements les plus récents à partir du dépôt central merge : la fusion automatique (ouf!) des différents changements (quand c est possible) d un fichier source Conflit (conflict) : l impossibilité (aïe!) de fusionner automatiquement des changements contradictoires. Nécessite une intervention manuelle. E. Remy (IUT d Arles) M / 37

8 Vocabulaire (2/2) Le tronc (trunk) : le répertoire principal de travail sur le dépôt, la version «normale» du logiciel en développement Branche (branch) : une copie dans un sous-répertoire du dépôt, servant à un ou plusieurs développeurs, pour travailler sur une variante du logiciel, tester une idée, etc. Le but est de ne pas «tout casser» et de ne pas empêcher les autres membres de travailler en même temps. Un merge ultérieur permettra, en cas de succès de cette variante, de réintégrer ce travail au trunk. Un tag : une version figée du programme à une version donnée, par exemple la première révision considérée stable peut être «tagée» sous le nom «1.0». C est techniquement, comme pour un branch, une copie en sous-répertoire du dépôt. Cela permet ensuite d assurer la correction de versions en cours d exploitation (passer de la 1.0 à 1.1) sans menacer le travail de long terme sur le trunk. Différence : c est la liste et le détail des changements qui ont été opérés entre deux révisions données. Subvension n est pas magique! Les conflits sont le signe d un problème humain de conception ou d organisation. Ils nécessitent l intervention d un humain pour les résoudre. Subversion n a pas conscience de ce que vous programmez! E. Remy (IUT d Arles) M / 37

9 Checkout initial Commande tapée une fois pour créer votre working copy locale. Mais rien n interdit d avoir plusieurs working copy locales différentes... Syntaxe : svn checkout URL_du_dépôt/répertoire_du_dépôt Demande en général de s identifier (login/password) La commande crée un répertoire qui porte le même nom que le dépôt : c est votre copie de travail! La commande donne une trace des opérations effectuées : la liste de chaque fichier ajouté «A» à la copie locale, et pour finir le numéro de révision auquel la copie de travail vient d être créée. Vous pouvez maintenant travailler sur votre copie de travail locale... E. Remy (IUT d Arles) M / 37

10 Update Pour récupérer les avancées dont le dépôt est déjà informé mais dont votre copie de travail n a pas encore bénéficié. Syntaxe (depuis l intérieur de la copie de travail) : svn update La commande donne une trace des opérations effectuées : les fichiers ajoutés «A», les automatiquement modifiés/merged «M» (Ouf!), les détruits «D» et les fichiers qui sont en conflit «C» (Aïe!). Lorsqu un conflit apparaît, vous avez plusieurs choix : Accepter la version du dépôt (et donc perdre la vôtre) ; Garder la vôtre en aveugle (et donc ignorer celle du dépôt) ; Regarder les différences entre les deux (ce qui n apporte aucune solution mais peut être pratique pour décider) (attention, les différences sont montrées avec la syntaxe de la commande UNIX diff... Pas très difficile à comprendre mais au début, ça surprend) ; Reporter à plus tard la résolution du conflit, ce qui est le cas le plus fréquent. E. Remy (IUT d Arles) M / 37

11 Résoudre un conflit (1/2) Lorsqu un conflit apparaît sur le fichier «truc.cpp» entre votre version (basée sur la révision 52) et celle du dépôt (qui est en révision 53), plusieurs choses apparaissent dans votre copie de travail : le fichier Truc.cpp.mine : c est votre version du fichier ; le fichier Truc.cpp.r52 : c est la version à partir de laquelle vous avez débuté votre travail (appelée BASE dans le vocabulaire de Subversion) ; le fichier Truc.cpp.r53 : c est la version qui provient de l actuelle mise à jour à la révision 53 (appelée HEAD) ; le fichier Truc.cpp n est plus du C++ correct car il contient désormais des sections balisées par «<<<<.mine», «>>>>.r53» montrant les variantes des lignes concernées. Vous devez modifier les lignes de Truc.cpp pour en refaire un fichier C++ correct. En général, il est simple de comprendre la source du conflit et donc de fusionner les versions. Si ce n est pas le cas, envisagez de discuter avec les autres membres du projet (en particulier, celui qui est à l origine des changements présents sur le dépôt) pour trouver la meilleure solution. E. Remy (IUT d Arles) M / 37

12 Résoudre un conflit (2/2) Une fois le fichier Truc.cpp totalement corrigé et de nouveau fonctionnel (ça compile et ça marche), vous devez indiquer que le conflit sur le fichier Truc.cpp est résolu en tapant : svn resolved Truc.cpp Cette commande fait disparaître toutes les variantes du fichier (Truc.cpp.mine, Truc.cpp.r52, Truc.cpp.r53) pour ne laisser que Truc.cpp. Si tous les conflits sont résolus, et que votre copie de travail est à jour avec le dépôt, vous pouvez tenter de transmettre votre travail au dépôt... Il arrive que le temps que vous corrigiez tous vos conflits, un collègue crée une nouvelle revision sur le dépôt, ce qui vous amène à corriger de nouveaux conflits... Alors sachez rester calme et patient : il ne l a pas fait pour vous rendre chèvre, et c est à vous de vous en sortir! Lui aussi aura à fusionner vos changements. Rien n interdit de s entendre (par ailleurs et par avance) parmi les membres du groupe pour éviter de créer trop de conflits... E. Remy (IUT d Arles) M / 37

13 Commit Sert à transférer votre travail sur le dépôt En cas de succès, cela produira une nouvelle revision, que vos collègues pourront à leur tour récupérer, etc. Il est impératif de préparer (éventuellement en prenant des notes pendant votre travail) une synthèse textuelle des changements que vous avez apportés au projet et de pourquoi vous les avez effectués. Par exemple, «j ai rendu le membre machin de la classe truc privé pour améliorer la sécurité générale, puis ajouter tous les accesseurs nécessaires, et modifié les fonctions qui se servent désormais de ces accesseurs». Syntaxe (depuis la copie de travail) : svn commit (qui fait intervenir un éditeur de texte pour que vous puissiez taper le message) ou bien svn commit m "Ici votre message.." ou encore svn commit F message.txt (où le fichier contient vos commentaires). Ne pas mettre de message (ou en mettre un médiocre) nuit au travail d équipe et à la vie du projet. À l issue du commit, votre copie de travail est à la nouvelle révision ainsi produite : pas besoin de vous mettre à jour. E. Remy (IUT d Arles) M / 37

14 Status Sert à regarder dans quel état est chacun des fichiers de la copie de travail. Syntaxe (depuis la copie de travail) : svn status Liste chaque fichier avec les mêmes codes que ceux vus pour update, plus quelques codes (simples!) : «?» pour un fichier qui n est pas soumis au versionage, etc. Pratique pour savoir où on en est quand il y a beaucoup de changements, et en particulier, utile pour savoir si il reste des fichiers en conflit! E. Remy (IUT d Arles) M / 37

15 Consultation des traces Pour voir l historique des messages des commit qui ont amenés à la revision actuelle. Syntaxe (depuis la copie de travail) : svn log less (en se servant de la commande UNIX de pagination pour ne pas être surchargé de centaines de lignes d un coup) C est là où vous allez détester tous ceux qui ne mettent pas un message digne de ce nom. E. Remy (IUT d Arles) M / 37

16 Gestion des fichiers Tous les fichiers ne sont pas soumis au versionnage! Il serait stupide de versionner les fichiers générés (.o,.exe, etc.)... et en plus, ça prendrait beaucoup de place sur le dépôt. Les fichiers versionnés doivent être explicitement ajoutés avec la commande svn add nom_fichier Sur le même principe, pour supprimer un fichier, il faut faire svn delete nom_fichier Pour des raisons techniques (pas géniales), le renommage ou le déplacement d un fichier, qui se fait par svn move nom_fichier_avant nom_fichier_apres, consiste à détruire l ancien et à créer le nouveau avec le même contenu. Il n y a aucune mémorisation de cette filiation entre les deux fichiers. Pour créer un sous-répertoire : svn mkdir nom_répertoire Toutes les autres commandes peuvent être trouvées grâce à l aide interne : svn help puis éventuellement svn help nom_commande... E. Remy (IUT d Arles) M / 37

17 Meld Un outil graphique Gnome qui permet de comparer visuellement, ainsi que de modifier de deux à trois fichiers de texte. (Pour KDE, il y a aussi kdiff3) Site Web L outil a gagné en fonctionnalités, et il permet même d étudier l état de toute une copie de travail : taper simplement «meld.» (en supposant que le répertoire courant «.» est dans la copie de travail). Ne permet cependant pas toutes les manipulations possibles avec la commande svn... (Est également compatible avec d autres gestionnaires de version : Git, Bazaar, Mercurial, etc.) E. Remy (IUT d Arles) M / 37

18 Deuxième partie Documentation du code E. Remy (IUT d Arles) M / 37

19 Documentation d un logiciel Un projet logiciel industriel est inévitablement accompagné de plusieurs types de documentations : une expression du besoin (ce qu à l IUT vous appelerez «cahier des charges») ; une description de l architecture globale du projet (à l IUT, le «cahier de conception») ; une documentation technique qui décrit le code lui-même, les algorithmes, les interfaces de programmation (API), etc. ; une documentation destinée à l utilisateur final, à l administrateur d un système, à une hotline. Nous allons nous intéresser maintenant à la documentation technique... E. Remy (IUT d Arles) M / 37

20 Documentation du code Dans un projet logiciel d une ampleur professionnelle, il est impératif d assurer la documentation du code produit : pour améliorer le travail de groupe («ça fait quoi cette fonction?») ; pour assurer la maintenance du programme («si on change ça, quel impact cela aura?») ; etc. Il est également apparu à l usage que la meilleure façon d avoir une documentation qui ne se sépare pas (retard, incohérence, voire absence) du code qu elle accompagne consiste à réclamer aux développeurs eux-mêmes d assurer sa rédaction, et ce directement dans le code au sein des commentaires. E. Remy (IUT d Arles) M / 37

21 Quelques outils Différents outils permettant de documenter du code ont vu le jour : pour JAVA, javadoc (système créé par Sun Microsystems pour la documentation du langage lui-même) ; pour Python, Sphinx ; pour C/C++ (et pleins d autres), Doxygen ; etc. La syntaxe des commentaires du langage est améliorée de balises spéciales reconnues par l outil de documentation et permettant au programmeur d indiquer des informations sur les classes, fonctions, paramètres, etc. Ces informations sont ensuite compilées pour produire une documentation dans un ensemble de formats possibles : HTML, PDF, DocBook, UNIX man page, aide Windows (.chm), RTF, XML, etc. Nous allons utiliser Doxygen en TP, et donc voir maintenant son usage... E. Remy (IUT d Arles) M / 37

22 Doxygen Doxygen est un logiciel libre Accepte : C, C++, Objective-C, C#, PHP, Java, Python, etc. Site Web de Doxygen Documentation sur le site Web : onglet «Documentation» Avant le TP, vous devrez lire les rubriques «Getting started» et «Documenting the code» E. Remy (IUT d Arles) M / 37

23 Doxygen Organisation générale La commande doxygen lit le fichier de configuration Doxyfile et en fonction de ce qui s y trouve, parcourt les fichiers sources et génère la documentation. La commande doxywizard permet de générer le fichier de configuration Doxyfile assez facilement... mais il est parfois nécessaire de peaufiner à la main derrière. E. Remy (IUT d Arles) M / 37

24 Doxygen Bases de la syntaxe (1/2) Souvent deux syntaxes possibles : JavaDoc : «/ Blah blah. /» ou bien «/// Blah blah.» Qt : «/! Blah blah. /» ou bien «//! Blah blah.» Le commentaire est à mettre immédiatement avant ce qu il décrit. Si vous activez «JAVADOC_AUTOBRIEF» (respectivement «QT_AUTOBRIEF») dans la configuration, la première phrase (jusqu au premier «.» rencontré) servira de descripion courte (brief). Sinon, il faut l indiquer explicitement, n importe où, avec «\ brief Blah blah.». On peut décrire un paramètre ou une donnée membre immédiatement après en indiquant : JavaDoc : «/ < Blah blah. /» ou bien «///< Blah blah.» Qt : «/!< Blah blah. /» ou bien «//!< Blah blah.» Pour une fonction, on peut aussi commenter les paramètres depuis l intérieur de la description : JavaDoc : «@param a est un entier qui sert à ça.» Qt : «\param a est un entier qui sert à ça.» E. Remy (IUT d Arles) M / 37

25 Doxygen Bases de la syntaxe (2/2) Pour le type de retour depuis l intérieur de la description : JavaDoc : «@return la valeur X+1.» Qt : «\return la valeur X+1.» Plein d autres mots-clés : \author, \warning, \image, etc. Possible de commenter aussi bien dans le «.hpp» que dans le «.cpp». Pour la mise en forme, le langage Markdown est utilisable (sections, listes, gras, souligné, liens, images, etc.). Grâce à L A TEX, il est également possible de mettre des formules mathématiques. Bien d autres possibilités... mais qui ne seront pas nécessaires pour le TP prévu : à creuser ultérieurement pendant les projets tuteurés, le stage,... E. Remy (IUT d Arles) M / 37

26 Doxygen Exemples Seule la syntaxe Doxygen (JavaDoc ou Qt) change dans l exemple ci-dessous. Syntaxe JavaDoc 1 / D e s c r i p t i o n br è ve de A. D e s c r i p t i o n l o n g u e 2 q u i s é tend s u r p l u s i e u r s l i g n e s. Et a u s s i 3 p l u s i e u r s p h r a s e s. Attention à ce dé t a i l. E. Remy 6 / 7 c l a s s A { 8 i n t a ; ///< L entier (description courte). 9 double b ; ///< Le réel (descr. courte). Description longue. 10 p u b l i c : 11 / Descrption courte. D es c ri pt i on plus longue. x l a v a l e u r à t r a i t e r. r e t u r n Le r é s u l t a t e s t un e n t i e r v a l a n t x / 15 i n t f o n c t i o n ( i n t x ) ; 16 } ; Syntaxe Qt 1 /! D e s c r i p t i o n br è ve de A. D e s c r i p t i o n l o n g u e 2 q u i s é tend s u r p l u s i e u r s l i g n e s. Et a u s s i 3 p l u s i e u r s p h r a s e s. 4 \ warning A t t e n t i o n à ce d é t a i l. 5 \ a u t h o r E. Remy 6 / 7 c l a s s A { 8 i n t a ; //!< L entier (description courte). 9 double b ; //!< Le réel (descr. courte). Description longue. 10 p u b l i c : 11 /! D e s c r p t i o n c o u r t e. D e s c r i p t i o n p l u s l o n g u e. 12 \param x l a v a l e u r à t r a i t e r. 13 \ r e t u r n Le r é s u l t a t e s t un e n t i e r v a l a n t x / 15 i n t f o n c t i o n ( i n t x ) ; 16 } ; E. Remy (IUT d Arles) M / 37

27 Troisième partie Contrôle de la qualité des programmes E. Remy (IUT d Arles) M / 37

28 Vie d un projet : le cycle en V Juste après le développement de chaque fonctionnalité, on implante les tests permettant de vérifier que chaque fonctionnalité détaillée est bien respectée. ñ tests unitaires Ensuite, le programme complet sera testé pour vérifier que l intégration de chacune des différentes unités ne fait pas apparaître un problème. ñ tests d intégration E. Remy (IUT d Arles) M / 37

29 Exemples de tests unitaires Quelques exemples d attentes légitimes : Sur la classe Polynome, on peut vouloir vérifier que calculer la valeur d un polynôme pour x 0 donne bien la valeur de la constante c 0 correspondant au monôme de degré 0. Toujours sur Polynome, on peut vérifier que la valeur pour x 1 est égale à la somme de tous les coefficients c i de chaque monôme. Sur la classe Ratio, on peut vouloir vérifier que créer un rationnel 1{0 déclenche bien une erreur à l exécution (et du type décidé à la conception). Sur chaque classe, on peut tester qu une construction de copie donne bien une instance dont chaque membre est identique à ceux de sa source. De manière générale, on cherchera à tester toutes les valeurs limites, les valeurs problématiques, etc. etc. Faillir à un test suite à une modification du code, alors qu il était validé auparavant signifie qu une régression a été introduite involontairement, et doit être analysée et corrigée. «Tester tout ce qui peut casser»... mais, dans le cas général, impossible de tout tester. Pour aller plus loin, depuis quelques dizaines d années, il devient possible des démontrer formellement (comme un théorème) les algorithmes et leurs propriétés... mais ça reste encore essentiellement un domaine de Recherche scientifique. E. Remy (IUT d Arles) M / 37

30 Alternatives au cycle en V Le cycle en V qui est le plus répandu comporte quelques inconvénients qui le rendent impropre à certains projets : Le développement de toutes les briques doit en général être fini avant d entamer les tests. Il est donc possible qu un problème majeur de conception trouvé au moment des tests, oblige à tout recommencer! Le client ne voit le programme que lors des dernières phases de test qui le concernent. Il ne peut donc pas indiquer si les tests prévus par l équipe de projet sont judicieux/corrects. Difficile d appliquer un cycle en V à un domaine mouvant (par exemple, le Web) ou incertain (la Recherche Scientifique) puisque les attentes ne peuvent pas toujours être fixées au début du projet autrement que sous forme de souhaits! D autres formes de gestion de projets sont donc apparues : extreme programming (XP) : faire beaucoup de cycles courts, appelés «run», enchaînant développement, tests, consultation du client, révision de la conception, etc. test driven development (TDD) : réaliser les tests d abord (en suivant un cahier de conception très détaillé) puis seulement après les choses à tester, afin d éviter que les tests soient guidés par des idées préconçues. XP+TDD sont souvent utilisés pour le développement en binôme : l un code les tests, l autre le source à tester. E. Remy (IUT d Arles) M / 37

31 Implanter des tests Quelques mécanismes de tests que vous pourriez utiliser en C++ (parmi un très large choix) : CppUnit : la variante C++ de la (célèbre) bibliothèque de tests JUnit créée pour Java ; boost :: test : la bibliothèque de tests faisant partie de l ensemble de bibliothèques C++ boost ; Qt Test : la bibliothèque de tests du projet Qt ; elle permet également de tester les applications graphiques ; GNU DejaGnu : la plate-forme de tests du projet GNU.... J ai choisi de vous faire manipuler boost :: test... E. Remy (IUT d Arles) M / 37

32 Généralités sur Boost Boost est un ensemble de bibliothèques et d outils portables, utiles en C++. D un très bon niveau de programmation C++. Les fonctionnalités de Boost ont vocation à être graduellement introduites dans la norme elle-même (par exemple les «smart pointers»). Site Web Très vaste nombre de compléments à la norme, avec (non-exhaustif) : Array, Container, Exception, Filesystem, Foreach, Geometry, Graph, Lambda, Locale, Math, Python, Ratio, Regex, Serialization, Thread, Timer, ublas, etc. boost :: test n est qu une de ces nombreuses fonctionnalités! Si vous codez une application portable ne dépendant pas déjà d une grosse bibliothèque (Qt, Microsoft MFC, etc.), vous devriez aller voir d abord dans boost si vous ne trouvez pas votre bonheur. E. Remy (IUT d Arles) M / 37

33 Module de test Vous créez un module de test (ici «MesTests»). Vous regroupez par thèmes vos tests individuels dans une ou plusieurs catégories de tests (nommée ici «GroupeUn»). Structure générale d un programme de test : test0.cpp 1 #d e f i n e BOOST_TEST_MODULE MesTests 2 #i n c l u d e <b o o s t / t e s t / u n i t _ t e s t. hpp> 3 4 // Ici vos includes, déclarations, etc. 5 6 BOOST_AUTO_TEST_CASE( GroupeUn ) 7 { 8 // Mettez ici vos tests 9 } L exécution affichera le détail ainsi qu un bilan des tests réussis et échoués. Attention : il n y a pas de main()! E. Remy (IUT d Arles) M / 37

34 Quelques tests possibles BOOST_CHECK(exp); : Si exp est faux, une erreur comportant le texte de exp est affichée. Les tests se poursuivent. BOOST_REQUIRE(exp); : Si exp est faux, le message est affiché puis une exception est lancée. Dans le cas général, cette exception arrêtera la série de tests. Ce test est donc prévu pour les cas où les tests ultérieurs ne pourraient pas être effectués si celui-là rate. if (exp) BOOST_ERROR("Ouch..."); : similaire à BOOST_CHECK(exp); mais en ayant le contrôle direct sur le if () et le message d erreur. if (exp) BOOST_FAIL("Ouch..."); : idem mais pour BOOST_REQUIRE(exp);. BOOST_CHECK_MESSAGE(exp,msg); : Si exp est faux, l expression msg (qui peut être complexe et contenir l opérateur <<) est affichée à la place du message standard de BOOST_CHECK(exp);. BOOST_CHECK_EQUAL(exp1,exp2); : rate si les deux expressions exp1 et exp2 ne sont pas égales. Affiche explicitement les valeurs de exp1 et exp2. E. Remy (IUT d Arles) M / 37

35 Exemple (1/2) Quelques exemples de tests : test1.cpp 1 #d e f i n e BOOST_TEST_MODULE STD_STRING_TESTS 2 #i n c l u d e <b o o s t / t e s t / u n i t _ t e s t. hpp> 3 4 #i n c l u d e <s t r i n g > 5 u s i n g namespace s t d ; 6 7 BOOST_AUTO_TEST_CASE( C o n s t r u c t i o n ) 8 { 9 s t r i n g s1, s2 ( "C++" ) ; 10 BOOST_CHECK_EQUAL( s1. l e n g t h ( ), 0 ) ; 11 BOOST_CHECK_EQUAL( s2. l e n g t h ( ), 3 ) ; 12 } BOOST_AUTO_TEST_CASE( C o n c a t e n a t i o n ) 15 { 16 s t r i n g s1 ( " H e l l o " ), s2 ( " w o r l d! " ) ; 17 s1+=s2 ; // Concaténation 18 BOOST_CHECK_EQUAL( s1. l e n g t h ( ), 1 2 ) ; 19 BOOST_CHECK( strcmp ( s1. c _ s t r ( ), " H e l l o w o r l d! " )==0); 20 } E. Remy (IUT d Arles) M / 37

36 Exemple (2/2) boost :: test étant implantée sous Linux en bibliothèque à liaison dynamique, il y a deux choses à rajouter lors de la compilation : il faut définir le symbole BOOST_TEST_DYN_LINK qui indique aux includes que la bibliothèque de test est dynamique ; il faut lier votre programme à la bibliothèque «boost_unit_test_framework». On a donc une ligne de compilation de la forme : g++ D BOOST_TEST_DYN_LINK test1.cpp lboost_unit_test_framework o test1 L exécution, par «./ test1», donne le message suivant (aucun test échoué) : Running 2 test cases... *** No errors detected E. Remy (IUT d Arles) M / 37

37 The End Avez-vous des questions? E. Remy (IUT d Arles) M / 37