Anatomie du test — ForumPHP12Histoire            Présentation
Bonjour à tous ! Je mappelle Frédéric Hardy. Jai commencé à mettre en œeuvre des tests sans le sa-voir en 1995 lorsque jai...
cialée dans la sécurité et sûreté du logiciel. Je suis également contributeur de divers logicielsopen-source comme PHP, Mo...
Il était une fois une équipe de développeurs qui souhaitait concevoir un programme répondant à unbesoin avec la meilleure ...
pour système sous test sous certaines conditions et contraintes, pour à la fin vérifier la sortie ou létatde ce SUT.Dans le ...
Les tests suivent tous ce processus à quelques nuances près.Cependant, il est nettement plus confortable pour le développe...
Test unitaireEt avant de tester le programme dans sa totalité, il est plus évident de tester des petites parties, lesunes ...
Et pour se faciliter encore plus la tâche, ils ont utilisé un framework de tests unitaires, car cest un ou-til dont le but...
de qualifier la qualité des tests. Tout ces facteurs nous permettent de savoir quelle confiance avoirdans notre code.Le choi...
Notre équipe écrit donc des tests a posteriori de la rédaction de leur code avec leur framework detests unitaires favori. ...
De plus, ils se sont aperçus quils développaient des fonctionnalités dont ils navaient pas besoin, cequi leur faisait enco...
lavenir, nos développeurs ont décidé de faire linverse : écrire les tests unitaires a priori.                             ...
Cette méthode impose un développement itératif qui facilite la conception du code. Lorsque lun denos développeurs veut écr...
Cest le signal qui autorise le développeur a écrire du code mais juste ce qui est nécessaire pour exé-cuter le test avec s...
Évidemment, au cours de ce processus, une modification du code peut invalider un test déjà existant.Nous parlons de régress...
Heureusement, une métrique très utile dans le cas des tests unitaires est la couverture du code. Du-rant lexécution dun te...
(orienté) représente un saut dun nœud vers un autre. Une exécution dun test sera représenté par unchemin dans ce graphe. D...
Ils se partagent ainsi le même écran, le même clavier et la même souris.En dehors de léquipe, certain ont pensé que cétait...
Et dailleurs, pour y parvenir au mieux, nos développeurs pratiquent de temps à autre le ping-pong.Lun des deux rédige alor...
nômes sont très souvent modifiés et le partage des connaissances se fait donc au fil de leau de ma-nière transparente. Les m...
Un mock est capable de simuler une dépendance. Son comportement est spécifié par le testeur. Grâceaux mocks, il devient pos...
ils ne dépendent daucune contrainte technique et sexécutent beaucoup plus rapidement que leurséquivalents du monde réel. L...
Toutefois, même si les parties unitaires étaient de qualité, des erreurs pouvaient apparaître au mo-ment dassembler ces pa...
Test structurelEn fait, nous manipulons toujours du code, nous avons toujours accès au code source. Et quand noustestons à...
A linstar du test unitaire ou dintégration, le test fonctionnel doit valider le comportement du pro-gramme mais, une fois ...
Cest la raison pour laquelle notre équipe a mis en place une plateforme dintégration continue qui ré-cupère les versions s...
Pour cela, il leur a fallu mettre en œuvre trois types de tests différents, chacun dentre eux étant dédiéà un objectif cla...
Tout ce qui précède nest donc pas une recette magique permettant décrire des tests pertinents et debonne qualité car il fa...
cest le test fonctionnel ! Quand on ne connaît pas le code ou que lon ny a pas accès, on est en boîtenoire. On a évoqué un...
Du coup, voici quelques outils que vous pourrez utiliser. Pour du test structurel (white-box) manuelen PHP :   ✪    atoum ...
Anatomie du test
Upcoming SlideShare
Loading in...5
×

Anatomie du test

1,379

Published on

Le test, qu'il soit unitaire ou fonctionnel, est à la mode dans le monde du développement logiciel, suite entre autre à la mise en œuvre croissante des méthodes agiles et notamment de l'intégration continue ou des méthodes de développement telles que le TDD, le BDD ou la programmation par contrat. Récemment, ce phénomène a encore été amplifié au sein de la communauté PHP par l'apparition aux côtés de l'incontournable PHPUnit d'outils plus originaux tels que Behat, Praspel ou atoum qui permettent au développeur de rédiger des tests plus simplement. Pourtant, nous constatons tous les jours que le test conserve une grande part de mystère pour la plupart des développeurs, Bien souvent, ces derniers ne savent pas quoi tester, et encore moins comment écrire un test efficace ou mettre en place une politique de test pertinente. Certains s'interrogent par exemple sur la pertinence de leurs tests, se demandent s'il faut absolument tout tester, d'autres s'il est possible de tester la création d'un fichier, voir même s'il est intéressant de le faire, tandis que d'autres se demandent où se situe la frontière entre le test unitaire et le test fonctionnel ou s'il est nécessaire de tester toutes les méthodes d'une classe, alors que d'autres encore ne savent tout simplement pas par où commencer. Durant cette conférence, nous allons tenter, à l'aide de nos expériences respectives de créateur de framework de tests et de doctorat en informatique spécialisé dans le test, de répondre aux questions récurrentes que se pose une personne confrontée à la mise en place d'une politique de qualité logicielle en général et à l'écriture d'un test logiciel en particulier. À l'issue de cette foire aux questions didactique et interactive, vous devriez être capable d'aborder le test, indépendamment de sa nature, de manière plus sereine et efficace et produire ainsi un logiciel de la qualité que vous désirez.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,379
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
40
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Transcript of "Anatomie du test"

  1. 1. Anatomie du test — ForumPHP12Histoire Présentation
  2. 2. Bonjour à tous ! Je mappelle Frédéric Hardy. Jai commencé à mettre en œeuvre des tests sans le sa-voir en 1995 lorsque jai débuté ma formation universitaire, avant de commencer à réellement lesmettre en œeuvre en 2005. Jai donc appris le test empiriquement, en les mettant en pratique dans lecadre de projets plus ou moins complexes. Depuis, jai créé le framework de tests unitaires atoum etjen suis le développeur principal.Bonjour à tous ! Je mappelle Ivan Enderlin. Je prépare actuellement une thèse en Informatique, spé-
  3. 3. cialée dans la sécurité et sûreté du logiciel. Je suis également contributeur de divers logicielsopen-source comme PHP, Mozilla, Debian etc. Je suis enfin auteur et développeur principal de Hoa,un ensemble de bibliothèques PHP. IntroductionAujourdhui, le test devient à la mode dans le monde industriel. Les outils permettant de les mettre enœuvre sont de plus en plus nombreux et toujours plus évolués ; les techniques de travail changenttout comme les mentalités ; bref le test se démocratise gentiment. Cependant, linformation à leur su-jet est souvent fragmentée et parcellaire, si bien que la plupart des développeurs ont des difficultés àles appréhender correctement de manière globale et se posent beaucoup de questions.Lhistoire que nous allons vous raconter a pour but dapporter quelques réponses aux questions quinous ont été le plus souvent posées.
  4. 4. Il était une fois une équipe de développeurs qui souhaitait concevoir un programme répondant à unbesoin avec la meilleure qualité et assurance possible, et afin dy arriver, ils décidèrent dutiliser lestests. DéfinitionUn test permet de confronter deux mondes : théorique et pratique. Lobjectif est dexécuter un SUT
  5. 5. pour système sous test sous certaines conditions et contraintes, pour à la fin vérifier la sortie ou létatde ce SUT.Dans le test dit manuel, cest le testeur qui va écrire toutes les conditions dexécution du SUT.Et les oracles permettent de calculer les verdicts des tests : tout simplement si les tests ont été un suc-cès ou un échec.
  6. 6. Les tests suivent tous ce processus à quelques nuances près.Cependant, il est nettement plus confortable pour le développeur de faire exécuter les tests par unemachine, car elle est capable de les exécuter aussi souvent que nécessaire, automatiquement, et beau-coup plus efficacement et rapidement.À ce stade, on parle de vérification de programme.
  7. 7. Test unitaireEt avant de tester le programme dans sa totalité, il est plus évident de tester des petites parties, lesunes après les autres. Nous allons donc chercher quelles sont les parties « atomiques » de notre pro-gramme, et le plus souvent, ce seront les fonctions ou les méthodes des classes. Pour faire une méta-phore, ce serait comme construire une maison sans avoir confiance dans ces fondations.Nous parlons alors de tests unitaires, puisquils ont pour but de vérifier le fonctionnement de la pluspetite unité de code existante, qui est alors le SUT évoqué précédemment.Notre équipe de développeurs a donc commencé à écrire du code, puis ensuite à rédiger les tests cor-respondants afin de les exécuter régulièrement. Cela leur a été dautant plus facile quun test unitairesécrit souvent dans le même langage que celui utilisé pour écrire le code.
  8. 8. Et pour se faciliter encore plus la tâche, ils ont utilisé un framework de tests unitaires, car cest un ou-til dont le but est dorganiser, faciliter et simplifier lécriture et lexécution de un ou plusieurs tests(dans ce cas, on parle de suite de tests). Un tel framework doit également être capable de produiredes rapports dans différents formats qui permettront aux développeurs de pouvoir localiser avec pré-cision les tests qui ont échoué et la raison de cet échec.Ces rapports peuvent également contenir dautres informations, notamment des métriques permettant
  9. 9. de qualifier la qualité des tests. Tout ces facteurs nous permettent de savoir quelle confiance avoirdans notre code.Le choix dun framework de test unitaires a été relativement simple pour notre équipe de développeurcar ils ont tout simplement expérimentés ceux qui leur semblaient intéressants. Leur choix a été tota-lement subjectif, mais ce nest pas un mal car limportant nest pas tant loutil choisi que le fait dêtreefficace avec.Toutefois, le choix nest pas anodin car ces outils sont en général très peu compatibles entre eux, etpar conséquence, il ny a pas de solution simple et rapide permettant den changer.
  10. 10. Notre équipe écrit donc des tests a posteriori de la rédaction de leur code avec leur framework detests unitaires favori. Cependant, ils nont pas tardé à réaliser que cette façon de faire présentait desinconvénients significatifs. TestabilitéTout dabord, ils se sont aperçus que pour être testable, leur code devait forcément suivre un certainnombre de bonnes pratiques de développement, et le fait décrire leurs tests a posteriori rendait cettecontrainte difficile à satisfaire. Ils étaient alors obligé de modifier le code concerné et de faire plu-sieurs fois le même travail.
  11. 11. De plus, ils se sont aperçus quils développaient des fonctionnalités dont ils navaient pas besoin, cequi leur faisait encore perdre plus de temps.Enfin, lors de la mise en œuvre de leur code au sein des tests, ils se rendaient parfois compte quilnétait pas pratique à utiliser, du fait dune API mal pensée ou peu adaptée au contexte dutilisation.Ces trois problèmes étant induits par le fait décrire les tests unitaires après avoir écrit le code. À
  12. 12. lavenir, nos développeurs ont décidé de faire linverse : écrire les tests unitaires a priori. Test Driven DevelopmentCe faisant, ils ont donc commencé à appliquer une méthode de développement connue sous lacro-nyme TDD pour Test Driven Development.
  13. 13. Cette méthode impose un développement itératif qui facilite la conception du code. Lorsque lun denos développeurs veut écrire du code, il commence par écrire le test le plus simple possible permet-tant de le décrire, et en général il consiste à instancier une classe et à appeler la méthode devant êtretestée. Le développeur exécute alors ce test unitaire, qui aboutit forcément sur un échec puisque lecode correspondant nexiste pas encore.La plupart des frameworks de tests matérialise léchec sous la forme dun message écrit en rouge,doù lexpression « la barre est rouge ».
  14. 14. Cest le signal qui autorise le développeur a écrire du code mais juste ce qui est nécessaire pour exé-cuter le test avec succès et que la « barre devienne verte ».Comme la méthode de travail est itérative, le développeur recommence ce processus en écrivant unnouveau test et ainsi de suite jusquà ce que le code réponde à ses besoins. Régression
  15. 15. Évidemment, au cours de ce processus, une modification du code peut invalider un test déjà existant.Nous parlons de régression. Cependant, grâce aux tests justement, ces régressions sont détectées im-médiatement et peuvent être corriger rapidement grâce aux rapports générés par notre outil de test.Malheureusement, il peut arriver que des régressions aient été introduites sans que les tests nepuissent les détecter immédiatement. Nos développeurs se sont demandés comment être sûr quuntest soit de bonne qualité ? Dans un premier temps, les tests doivent représenter les exigences denotre code ou de notre projet. Mais nous voulons que les tests apportent un élément de sûreté (notam-ment avec la détection de régression).Pour cela, nos développeurs ont écrit des tests positifs qui symbolisent un comportement normal,mais aussi des tests négatifs qui symbolisent un comportement anormal. Cette approche ajoute de lasûreté : le code fait ce quil doit faire et ne fait pas ce quil ne doit pas faire. CouvertureLes résultats étaient nettement plus satisfaisant et leur code était devenu de bien meilleur qualité.Mais ce nétait pas suffisant car dans certains cas, ils découvraient encore des erreurs inattendues etdifficiles à détecter. Ils ont voulu qualifier la qualité des tests, savoir à quel point ils pouvaient avoirconfiance dans leurs tests.
  16. 16. Heureusement, une métrique très utile dans le cas des tests unitaires est la couverture du code. Du-rant lexécution dun test, le framework utilisé va analyser quelle partie du code a été atteinte ou cou-verte. Une fois la suite de tests exécutée en entier, loutil agrège toutes ces données et nous fournit unrapport détaillé sur la couverture. Plus elle est importante et plus nos tests sont de qualité. A x <= 0 x > 0 x := -x B C x := 1 - x D x := -1 x /= -1 x := 1 E F x := x + 1 G writeln(x)Il existe plusieurs niveaux de couverture. En réalité, nous pouvons représenter un code par son CFGpour Control Flow Graph. Chaque nœud dans ce graphe représente un bloc de code et chaque arc
  17. 17. (orienté) représente un saut dun nœud vers un autre. Une exécution dun test sera représenté par unchemin dans ce graphe. Des couvertures évidentes apparaissent comme par exemple tous-les-arcs.Dautres sont plus difficiles comme par exemple tous-les-chemins. En effet, si notre code comporteune boucle, peut-être quune partie sera atteignable uniquement après i passages dans cette boucle ;cest la couverture tous-les-i-chemins. tous-les-chemins toutes-les-DU-chemins toutes-les-utilisations toutes-les-c- toutes-les-p- tous-les-i-chemins utilisations utilisations toutes-les-définitions tous-les-arcs tous-les-nœudsNous pouvons aussi prendre en compte la dépendance entre les variables, leurs utilisations etc., maislobjectif ultime étant la couverture tous-les-chemins.Malheureusement, selon les langages, rares sont les frameworks capables de détecter toutes les cou-vertures. La couverture la plus utilisée est tous-les-nœuds, elle reste faible mais cest toujours uneavancée ! ping-pongMais nos développeurs ont trouvé une solution supplémentaire pour améliorer la qualité de leur codedirectement à la source : travailler en binôme.
  18. 18. Ils se partagent ainsi le même écran, le même clavier et la même souris.En dehors de léquipe, certain ont pensé que cétait du gaspillage de ressources et quil fallait enconséquence arrêter immédiatement. Cependant, il leur a suffit de regarder attentivement les binômesen train de travailler pour quils reconnaissent que la paire travaille bien simultanément et en équipe.En effet, lorsque lun a le clavier, lautre porte un regard critique sur le code qui est écrit, ce qui luipermet de répérer les erreurs de syntaxe, le non respect des conventions de codage et de faire dessuggestions souvent bienvenues pour améliorer la lisibilité, la maintenance ou lefficacité du code oudes tests. De plus, deux cerveaux sont bien plus à même de répertorier lensemble des cas dutilisa-tion possibles pour du code.
  19. 19. Et dailleurs, pour y parvenir au mieux, nos développeurs pratiquent de temps à autre le ping-pong.Lun des deux rédige alors le test tandis que lautre écrit le code permettant de lexécuter avec succès.Les rôles sont régulièrement permutés afin déviter la lassitude et détecter plus derreurs.Les résultats sont très impressionnants mais cette façon de travailler est éprouvante car elle ne laisseaucun répit aux deux développeurs, et elle ne doit donc être utilisée quà bon escient. Un dernieravantage du binômage : chaque membre est amené à travailler sur lensemble du code, car les bi-
  20. 20. nômes sont très souvent modifiés et le partage des connaissances se fait donc au fil de leau de ma-nière transparente. Les membres de léquipe ont tous une vision globale du code du programme. MockUne vision globale mais pas totale. Dans certains cas, nos amis devaient travailler sur du code quinécessitait des parties encore non développées ou non finalisées, car le code a des dépendances. Parexemple, il arrive fréquemment quun test ait besoin daccéder à un système de fichiers, à une base dedonnées ou bien encore à une connexion réseau, un Web service etc.Or, si ce composant nexiste pas, cela est bloquant pour la tâche, et même sil existe, il nest pasévident de simuler un dysfonctionnement pour avoir une suite de test complète. Cest pourquoi nosdéveloppeurs ont décidé dutiliser les mocks.
  21. 21. Un mock est capable de simuler une dépendance. Son comportement est spécifié par le testeur. Grâceaux mocks, il devient possible de simuler des erreurs lors dune sauvegarde dans un fichier ou lorsdune connexion à une base de données ou encore à un réseau, tout en améliorant la portabilité destests. Un mock fait parti intégrante du test et il sera en conséquence toujours disponible indépendam-ment de son environnement dexécution.Nous remarquons aussi que les mocks améliorent la vitesse dexécution des tests car, étant virtuels,
  22. 22. ils ne dépendent daucune contrainte technique et sexécutent beaucoup plus rapidement que leurséquivalents du monde réel. Lorsquun mock simule une connexion à un réseau, la latence du réseauou des serveurs na donc plus aucune influence sur la vitesse dexécution des tests (sauf si le mock lespécifie bien entendu).La mise en œuvre des tests unitaires et plus particulièrement du TDD ont permis à notre équipe nonseulement de gagner en qualité, ce qui était lobjectif de départ, mais aussi en productivité et enconfiance. Dautres effets positifs navaient même pas été anticipés. Par exemple, au début du projet,ils avaient alloué du temps pour la rédaction des test a posteriori, temps qui sétait révélé bien sou-vent insuffisant.Or, avec le TDD, lécriture des tests revient à développer le code du programme, ce qui revient à direque le coût décriture des tests est confondu avec le coût du développement. Et cerise sur le gâteaux,les développeurs ont réalisé que les tests peuvent servir de documentation ! Il est donc devenu totale-ment inutile dallouer du temps spécifique à lécriture des tests ou dune catégorie de documentation,ce qui facilite la planification du projet et a permis daméliorer la maîtrise des délais. Mais aussi, àchaque instant, notre équipe était certaine que lexistant fonctionnait. Test dintégration
  23. 23. Toutefois, même si les parties unitaires étaient de qualité, des erreurs pouvaient apparaître au mo-ment dassembler ces parties. Pour reprendre la métaphore sur la maison, les briques sont toutes bienréalisées mais personne na pensé à regarder si elles sont compatibles entre elles.Pour cela, une technique complémentaire au test unitaire est le test dintégration. Le test dintégrationnest pas très différent dun test unitaire car le SUT est un agrégat dunités de code.
  24. 24. Test structurelEn fait, nous manipulons toujours du code, nous avons toujours accès au code source. Et quand noustestons à partir du code, nous appelons ça le test structurel ou le test white-box (qui comprend la no-tion de couverture, de CFG etc.). Des outils adaptés au test unitaire seront probablement adaptés autest dintégration.Mais attention, les métriques pour qualifier la qualité dun test dintégration ne seront pas les mêmes.Cest normal car les tests dintégrations viennent compléter les tests unitaires, ils offrent une valida-tion à un niveau supérieur. Un test dintégration se déroule dans un environnement très proche de ce-lui du monde réel une fois que toutes les dépendances ont été mises en place, a contrario des testsunitaires qui se basent sur des mocks. Le code peut se comporter différemment et dans ce contextedes bugs peuvent apparaîtrent. La complémentarité entre les techniques de tests est importante. Test fonctionnelArmés de leurs tests unitaires et dintégrations, notre équipe est donc maintenant certaine de disposerde briques élémentaires fiables et compatibles, nécessaires à la construction de leur programme. Ce-pendant, ces tests ne leur permettent pas de vérifier que le programme construit à partir de cesbriques de base répondra aux besoins de ses utilisateurs. Pour reprendre notre métaphore, la maisonest construite mais est-ce que la porte à 3 mètres du sol est pratique à utiliser ? Or, cest justement lerôle des tests fonctionnels de vérifier que le code du programme répond aux besoin de lutilisateur.
  25. 25. A linstar du test unitaire ou dintégration, le test fonctionnel doit valider le comportement du pro-gramme mais, une fois de plus, à un niveau supérieur. Cependant, il est très différent dans sa formecar il doit permettre de valider un comportement fonctionnel et non technique. Cest pourquoi il esttotalement indépendant à tout point de vue du langage utilisé pour le développement du programme.Il se présente le plus souvent comme un script essayant dexprimer des séquences de manière simpleet naturelle permettant damener le système dans un état particulier pour ensuite valider cet état.Lobjectif est de simuler un comportement type dun utilisateur. Intégration continueÉvidemment, pour que tout ça soit réalisable, il faut la dernière version disponible du programme,compilée, assemblée et utilisable par les outils de test. Or, réunir tous ces paramètres à chaque modi-fication du code est une tâche longue et fastidieuse !
  26. 26. Cest la raison pour laquelle notre équipe a mis en place une plateforme dintégration continue qui ré-cupère les versions successives du code à tester, exécute les tests, compile et assemble le programmesi tous les indicateurs sont au vert. Le cas échéant, des notifications sont émises rapidement afindavoir un retour immédiat. Ainsi, nos programmeurs gagnent vraiment en productivité et peuventcorriger leurs erreurs au plus tôt.Cependant, les tests fonctionnels ont posé un problème à nos développeurs car, par habitude, ils onteu tout dabord tendance à y décrire techniquement plutôt que fonctionnellement la façon dont le pro-gramme devrait fonctionner. Leurs premiers tests fonctionnels étaient étroitement lié au fonctionne-ment de leur code, et leur maintenance est vite devenue fastidieuse car chaque modification du codedevait obligatoirement être répercutée sur les tests concernées. Il leur a cependant suffit de se direque les tests fonctionnels devaient continuer à passer même après une refonte complète du code pourrésoudre ce problème. Les tests fonctionnels leur ont également permis de tester plusieurs interfacesutilisateur pour leur programme. En effet, un programme doit se comporter de la même façon indé-pendamment de la façon dont lutilisateur lutilise : en ligne de commande, via une interface gra-phique ou encore un navigateur Web. ConclusionNotre équipe de développement est donc aujourdhui heureuse et à donner naissance à beaucoup deprogrammes depuis ses premiers pas dans lunivers du test. Grâce à la mise en œuvre du TDD et destests unitaires, dintégration et fonctionnels, elle est aujourdhui parfaitement à même de livrer ducode fiable et répondant aux besoins de ses utilisateurs en toute confiance. Grâce au binômage, cha-cun deux a une vision plus globale du code et aucun membre de léquipe nest lexpert exclusif dunepartie du code. Lintégration continue leur permet de surveiller automatiquement que les modifica-tions ou les évolutions effectuées sur leur code na pas dinfluence négative.
  27. 27. Pour cela, il leur a fallu mettre en œuvre trois types de tests différents, chacun dentre eux étant dédiéà un objectif clair et étant complémentaire des autres.Notre histoire aurait pu être très différente car il ny a pas quune seule façon de mettre en œuvre cor-rectement des tests. Il existe dautres méthodes que le TDD, tout aussi pertinente, et différentes fa-çons de rédiger des tests, indépendamment de leur nature. De plus, notre histoire se déroule au paysdes « bisounours », où tout problème a une solution rapide et efficace avec un coût temporel ou fi-nancier nul, ce qui est très éloigné de la réalité. Dans le « vrai monde », il est en effet parfois néces-saire de devoir sadapter pour faire face à des contraintes temporelles ou financières qui ne nous per-mettent pas de mettre en œuvre la totalité des tests que lon souhaiterait utiliser. Dans ce contexte, leplus important est de garder à lesprit que même faire un unique test, à la condition quil soit bienécrit évidemment, est bien plus pertinent que de ne pas faire de test du tout. Enfin, en fonction dulangage de programmation utilisé et des outils employés, les problèmes rencontrés et leur solutionpeuvent être très différents.
  28. 28. Tout ce qui précède nest donc pas une recette magique permettant décrire des tests pertinents et debonne qualité car il faut de toute façon du temps et de lexpérience pour y parvenir. Écrire un test estun métier. One more thing : test automatiqueOn a surtout parlé de white-box mais vous aurez deviné quil existe aussi le black-box. En réalité,
  29. 29. cest le test fonctionnel ! Quand on ne connaît pas le code ou que lon ny a pas accès, on est en boîtenoire. On a évoqué un moyen de tester son programme avec des scripts écrits manuellement, mais ilexiste dautres techniques, plus coûteuses cependant et qui nécessitent plus de compétences, commele MbT pour le test à partir de modèle. Lidée est davoir un modèle formel qui décrit lévolution dusystème à travers une vision abstraite de son fonctionnement. Un modèle est souvent caractérisé parune spécification la plus formelle possible. Cest grâce à son aspect abstrait que le MbT permet de gé-nérer des suites de tests automatiquement mais aussi danalyser la conformance entre le modèle et lecode, normalement réalisés dos-à-dos par des équipes différentes. On peut également animer un mo-dèle pour détecter les erreurs de conceptions.Mais comme précisé, ça coûte cher et cest souvent dédié à des logiciels nécessitant une très haute sé-curité et sûreté. Heureusement, il existe le grey-box qui prend le meilleur des deux mondes ! On estsûr le code au niveau unitaire et on lannote avec des contrats. Un contrat est constitué dunepré-condition, dune post-condition et dinvariants. On peut sen servir de deux manières : utiliser lescontrats pour vérifier notre programme, un peu comme on le faisait avec du test unitaire manuel, oualors valider notre programme. Lidée est alors dutiliser la pré-condition pour générer des données detests et utiliser la post-condition et les invariants comme oracle.Vous aurez compris que les éléments clés dans le test automatique est la spécification (donnée parlutilisateur) et la génération des données (par la machine) : comment générer des données réalistes ?Il faut assurer la meilleure couverture possible et le plus efficacement possible. Que choisir : généra-tion aléatoire, statique, dynamique, concolic, fuzzing, search-based … ? Autant de domaines à dé-couvrir (sans mauvais jeu de mots) !Et cest bien beau de générer des suites de tests mais comment les maintenir : lesquelles conservées,lesquelles mettre à jour, lesquelles supprimées ? Et on na pas non plus parlé des tests paramétrés, nides tests à partir de scenarii etc.Heureusement que toutes ces questions ont des réponses, ou des bouts de réponses. En recherche, onvoit de plus en plus doutils « intelligents » qui mélangent plusieurs techniques et qui sont utilisésdans lindustrie … pour de vrai ! Noubliez pas que le test est un métier. One more thing2 : quelques outils
  30. 30. Du coup, voici quelques outils que vous pourrez utiliser. Pour du test structurel (white-box) manuelen PHP : ✪ atoum ; ✪ PHPUnit ; ✪ SimpleTest.Pour du grey-box automatique en PHP : ✪ Praspel.Pour du test fonctionnel (black-box) manuel en PHP : ✪ Behat.Pour du test fonctionnel (black-box) manuel pour interface graphique : ✪ CasperJS ; ✪ Sahi ; ✪ Selenium.Enfin, pour de lintégration continue : ✪ Squash ; ✪ Jenkins ; ✪ Sonar.Noubliez pas que les outils sont souvent polyvalents ! Merci !

×