Comment               tester du codecontenant des services web ?
Les services Web sont                                           massivement utilisésSuite à la démocratisation dInternet e...
Vous écrivez des testsOr, depuis quelque temps, afin daméliorer la qualité de votre code et donc de vos livrables, vous av...
Vos tests sont exécutés par        la machineVous exécutez donc ces tests très souvent, soit partiellement, soit complètem...
Les tests permettent de            corriger au plus tôt les erreursVous écrivez donc des tests unitaires, parfois même ava...
Services Web + tests =Or, lutilisation de services web dans vos tests peut vous poser un certain nombre de problèmes susce...
Le réseau nest pas fiableLe premier problème et non lun des moindres est que un ou plusieurs services web avec lesquels vo...
WTF?Mais en fait, peu importe la raison, puisque la conséquence est toujours la même, à savoir des tests qui ne passentpas...
Les tests sont alors             un handicapDans ce cas, vous aurez donc passé du temps à résoudre un problème dont vous n...
Le handicap                                           a un coût financierEt comme ils sont exécutés très souvent et très ré...
Le handicap induit           une perte de confianceDans le pire des cas, ceci peut vous amener à ne plus prendre le temps d...
Un autre problème posé par lutilisation de services web sont les politiques daccès à ces derniers.Un service peut en effet...
Tester un service     peut être coûteuxOr, par nature, vos tests sont exécutés très souvent.Il est donc très possible quil...
Les formalités daccès                                        peuvent être                                         laborieu...
Les services ralentissent           les testsDailleurs, en parlant de délais, du fait de sa relative lenteur par rapport à...
Déni de                                                            servicesJe passerais rapidement sur les problèmes du mê...
Désynchronisation                                         des donnéesEnfin, il est également possible que les réponses fou...
Mettre un service web dans                    un test, cest jouer à la                              roulette russeBref, ut...
Il faut simulerEn effet, un test valide le comportement de votre code en fonction de la réponse que ce dernier est censé r...
Simuler                          Permet de contrôlerAinsi, vous pourrez au cours de vos tests fournir à votre code les don...
Utilisez                                              votre propre                                            infrastructu...
Le réseau ralentit                                           toujours les testsCependant, cette solution présente toujours...
Le réseau ralentit                                           toujours les testsDe plus, cela ne règle pas totalement le pr...
Installer un proxy nest pas  forcément évidentCertes, pour contourner le problème, vous pourriez installer et configurer l...
Je vais donc maintenant vous présenter deux cas pratiques dutilisation de ces deux outils en mappuyant suratoum, le framew...
LadapteurUn adapteur est un objet qui joue le rôle de proxy entre une fonction native du langage et votre code.En clair, l...
Les mockSi ladapteur permet de surcharger les fonctions natives de PHP, le mock permet quand à lui de simuler uneinstance ...
Ce n’est pas une recette                        magique !Ladapteur et les mocks sont donc des outils puissants qui permett...
Prochain SlideShare
Chargement dans…5
×

Comment tester des services web ?

2 708 vues

Publié le

Aujourd'hui, les applications que nous développons sont souvent dépendantes de services Web dont nous n'avons pas la maîtrise, aussi bien fonctionnellement que techniquement. En effet, ces services peuvent se révéler être indisponibles à cause d'un problème d'accès au réseau, d'un incident technique chez leurs fournisseurs, de contraintes de sécurité, ou bien encore parce qu'ils ne sont pas encore opérationnels car en cours de développement. De plus, ces services peuvent être également payants et donc avoir un coût d'utilisation, soit en volume, soit à la transaction, très significatif. Dans ces conditions, développer du code reposant sur ces services peut être un vrai challenge, et il peut être encore plus difficile de le tester de manière unitaire. Au cours de cette conférence, nous verrons que atoum, un framework de tests unitaires simple, moderne et intuitif pour PHP ? 5.3, peut répondre à ces deux problèmatiques.

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 708
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1
Actions
Partages
0
Téléchargements
47
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Comment tester des services web ?

  1. 1. Comment tester du codecontenant des services web ?
  2. 2. Les services Web sont massivement utilisésSuite à la démocratisation dInternet en général et du Web en particulier, les services web sont aujourdhuimassivement utilisés par les programmes informatiques.Ils sont en effet très pratiques puisquils reposent sur le protocole HTTP et surtout parce quils permettent audéveloppeur de déléguer à des programmes tiers la réalisation de tâches complexes ou pour lesquelles il nedispose pas des données nécessaires.Il est ainsi par exemple possible dutiliser un service web pour calculer un itinéraire routier et le tracer sur unecarte géographique, pour interroger des bases de données publiques ou privées, pour effectuer des calculscomplexes sur une infrastructure dédiée ou bien encore pour authentifier des utilisateurs, et cette liste est très loindêtre exhaustive.Il nest donc pas rare pour vous, développeur daujourdhui, de devoir intégrer lutilisation de un ou plusieursservices web dans vos développements.
  3. 3. Vous écrivez des testsOr, depuis quelque temps, afin daméliorer la qualité de votre code et donc de vos livrables, vous avez décidé demettre en place des tests sous la forme de un ou plusieurs programmes informatiques qui vérifient lors de leurexécution que votre code se comporte effectivement comme il le doit.
  4. 4. Vos tests sont exécutés par la machineVous exécutez donc ces tests très souvent, soit partiellement, soit complètement, afin de vous assurer que lesdernières modifications que vous avez effectué sur votre programme nont pas eu dimpacts négatifs sur soncomportement.Et grâce à lintégration continue, ces tests sont même exécutés automatiquement dans leur intégralité, sans lamoindre intervention de votre part.
  5. 5. Les tests permettent de corriger au plus tôt les erreursVous écrivez donc des tests unitaires, parfois même avant de concevoir le code de votre programme, car vousfaites du développement piloté par les tests, et afin davoir la meilleure couverture possible, vous complétez cestests unitaires par des tests dintégrations, eux-mêmes garantis par des tests fonctionnels et des tests manuels.Ainsi, vous pouvez détecter et corriger au plus tôt la plupart sinon la totalité de vos erreurs et garantir la qualité devotre code et le respect des besoins fonctionnels de lutilisateur final à votre client.
  6. 6. Services Web + tests =Or, lutilisation de services web dans vos tests peut vous poser un certain nombre de problèmes susceptibles devous donner extrêmement mal au crâne, voir même vous donner lenvie dabandonner toute politique relative à laqualité logicielle.
  7. 7. Le réseau nest pas fiableLe premier problème et non lun des moindres est que un ou plusieurs services web avec lesquels vous devezcommuniquer peuvent très bien ne pas être accessibles au moment de lexécution de vos tests, et cela pour demultiples raisons.Votre connexion à Internet peut en effet ne pas être opérationnelle parce que la femme de ménage a débranché parinadvertance un câble réseau, parce que le fournisseur du service rencontre des difficultés techniques ou vous aretiré par erreur vos autorisation daccès, ou bien encore parce que votre administrateur réseau préféré vient demettre en place un PALC, connu également sous le nom de « Proxy À la Con ».Ou bien encore parce quun ouragan a rendu inaccessible une partie dInternet et quen conséquence, votrefournisseur de service est obligé de ravitailler en carburant ses groupes électrogènes en trimbalant des seaux decarburants dans des escaliers sur plusieurs étages.
  8. 8. WTF?Mais en fait, peu importe la raison, puisque la conséquence est toujours la même, à savoir des tests qui ne passentpas.Vous allez alors devoir en chercher la raison, alors quà première vue, il ny a strictement aucune raison pour quevous obteniez des échecs.Et dans la plupart des cas, vous ne pourrez rien faire pour corriger le problème, car sil peut être plus ou moinsfacile pour vous dêtre à nouveau connecté à Internet si lorigine du problème est un câble débranché, vous nepourrez par contre pas faire grand chose pour faire disparaître les conséquences dun ouragan ou contourner unPALC (du moins en restant dans la légalité).
  9. 9. Les tests sont alors un handicapDans ce cas, vous aurez donc passé du temps à résoudre un problème dont vous nêtes pas responsable et quevous naurez pas les moyens de résoudre.Les tests ne seront alors non plus avantage mais un handicap, car ils vous feront perdre du temps au lieu de vousen faire gagner.
  10. 10. Le handicap a un coût financierEt comme ils sont exécutés très souvent et très régulièrement en fonction de lavancement de vos développements,les tests peuvent au final vous faire perdre énormément de temps et donc dargent, notamment si votre connexion àInternet nest pas fiable ou si les services web que vous utilisez sont très souvent inaccessibles.
  11. 11. Le handicap induit une perte de confianceDans le pire des cas, ceci peut vous amener à ne plus prendre le temps de chercher la cause des tests en échecs,car vous serez plus ou moins persuadé systématiquement que les coupables sont les services web.En conséquence, vos tests seront devenus inutiles et par ricochet, vous ne serez alors plus en mesure dêtre certainque ce nest pas votre code qui provoque ces échecs.Vous ne tarderez alors plus à arrêter de les développer et de les maintenir, avec tout les risques que cela impliqueen terme de qualité et les problèmes correspondants qui ne manqueront pas de survenir à plus ou moins courtterme.
  12. 12. Un autre problème posé par lutilisation de services web sont les politiques daccès à ces derniers.Un service peut en effet par exemple ne vous autoriser quun certain nombre daccès par jour, semaine, mois ouannée, pour des raisons techniques et/ou commerciales, ou bien encore son utilisation peut être facturée enfonction de son utilisation.
  13. 13. Tester un service peut être coûteuxOr, par nature, vos tests sont exécutés très souvent.Il est donc très possible quils consomment lintégralité du quota daccès quil vous a été alloué et que vous nayezalors plus la possibilité dexploiter le service en production, notamment si au cours de vos développements vousavez généré par mégarde une ou plusieurs boucles infinies qui ont généré plusieurs milliers de requêtes enquelques secondes sur le service.Dans le pire des cas, vous pourrez même vous retrouver sur une liste noire pour cause dutilisation abusive duservice concerné et donc dans limpossibilité totale de lutiliser pendant une période plus ou moins longue, enfonction du bon vouloir de son fournisseur.Et pour la même raison, si laccès au service implique un coût financier, vous pouvez vite vous retrouver avec unefacture conséquente, alors même que vous navez même pas commencé à utiliser le service en production.
  14. 14. Les formalités daccès peuvent être laborieusesJajoute que même lorsquil nest pas utilisé directement dans le cadre dun test, un service web peut être unproblème pour vos développement.En effet, il peut sécouler un certain temps avant que vous obteniez du fournisseur du service les informationsnécessaires permettant de lexploiter, à cause par exemple dune négociation commerciale qui traîne en longueurou bien parce que son utilisation nécessite lobtention dun certificat SSL qui permettra de vous authentifier et quepour lobtenir, vous devez remplir un dossier de 500 pages qui sera traité dans les meilleurs délais, à savoir dici 15à 300 jours, à la condition bien évidemment que vous ayez bien fourni tous les justificatifs demandés.Or, en toute logique, vous ne pourrez commencer à travailler avec le service concerné et donc à lintégrer dans vostests que lorsque vous disposerez de ces informations, et si vous les obtenez trop tardivement, vous serez contraintde développer « à larrache » ou bien vous ne parviendrez pas à tenir vos délais de livraison, ce qui peut encoreune fois avoir de sérieuses répercussions financières.
  15. 15. Les services ralentissent les testsDailleurs, en parlant de délais, du fait de sa relative lenteur par rapport à du code exécuté localement, un servicesweb est susceptible de ralentir plus ou moins significativement lexécution de vos tests.Les performances dun service web dépendent en effet non seulement de celles de votre connexion au réseau quilhéberge, mais également de celles de linfrastructure technique de son fournisseur et de la qualité de son code.Et si par hasard lun des maillons de cette chaîne présente une faiblesse, vos tests vont sexécuter plus ou moinslentement parce que le service naura pas été capable de vous répondre suffisamment rapidement.Et si daventure vous utilisez un service très populaire ou qui est en train de devenir à la mode, vos tests peuventtout simplement échouer car le fournisseur ne dispose pas des infrastructures nécessaires pour répondrecorrectement à lensemble des requêtes quil reçoit.
  16. 16. Déni de servicesJe passerais rapidement sur les problèmes du même type posés par les attaques de type dénie de service quepeuvent subir vos fournisseurs ou vous-même et qui rendront totalement inutilisables vos services web pendantune durée indéterminée.
  17. 17. Désynchronisation des donnéesEnfin, il est également possible que les réponses fournies par un service web évoluent au cours du temps parceque les données quil utilise ont été corrigées ou enrichies.Or, vous ne vous en rendrez compte que lorsque vos tests seront en échec parce que les données quils ont reçu deces services ne sont plus celles que vous aviez prévue lors de leur rédaction.
  18. 18. Mettre un service web dans un test, cest jouer à la roulette russeBref, utiliser un services web au sein dun test revient à jouer à la roulette russe.Souvent, il ny a aucun problème, mais lorsquil y en a un, ses conséquences peuvent être très importantes.Heureusement, il existe une solution permettant de résoudre toutes ces problèmatiques.En effet, la totalité des problèmes que vous pouvez être amené à rencontrer en utilisant des services web dans vostest sont induits par le fait que vous navez absolument aucun contrôle sur ces derniers.Pour les éviter ou les résoudre, il vous suffit donc dobtenir ce contrôle, même si cela semble à première vueimpossible.En effet, par définition, un service web est indépendant de votre code et vous navez donc aucun moyen de définirson comportement.Cependant, vos tests ont-ils réellement besoin dun véritable service web pour valider le fonctionnement de votrecode ?Sont-ils réellement obligés de se connecter à un réseau, dinterroger un serveur et dattendre sa réponse ?La réponse est négative.
  19. 19. Il faut simulerEn effet, un test valide le comportement de votre code en fonction de la réponse que ce dernier est censé recevoirde la part du ou des services web.La seule chose dont a réellement besoin votre code pour fonctionner correctement est donc une réponse de la partdu service web et la façon dont cette réponse est obtenue importe peu.Létablissement de la connexion au réseau hébergeant le service, linterrogation de son serveur et lattente de saréponse sont un moyen et non une fin pour acquérir les données nécessaires à votre code.La solution a lensemble des problèmes que vous êtes susceptible de rencontrer en tant que développeur lorsquevous testez du code utilisant un ou plusieurs services web est donc de simuler ces derniers.
  20. 20. Simuler Permet de contrôlerAinsi, vous pourrez au cours de vos tests fournir à votre code les données requises, sans être dépendant dautrechose que de votre propre infrastructure technique et logiciel.De plus, vous pourrez alors définir très précisément le comportement des « services » que vous utilisez enfonction des différents tests que vous souhaitez effectuer.Vous pourrez donc simuler par exemple un refus dauthentification, une réponse incomplète ou dans un formatdifférent de celui que vous aviez prévu, labsence de réponse, bref, tout ce qui pourra vous permettre de valider lecomportement de votre code lorsquun service ne se comporte pas comme il le devrait.Et à contrario, vous pourrez tout aussi bien simuler une réponse correcte afin de vérifier que votre code secomporte comme il le doit lorsque tout se passe bien.
  21. 21. Utilisez votre propre infrastructure !Pour cela, une première solution consiste à utiliser dans le cadre de vos tests un serveur de votre propreinfrastructure dédié à la simulation des services web.Vous pourrez alors en définir le comportement en fonction des besoins et il vous suffira dy faire appel dans vostests en lieu et place des véritables services web.La seule contrainte induite par cette solution, outre le fait quil vous faut disposer du budget, du matériel et descompétences nécessaires à son installation et à sa configuration, est que vous devrez avoir la possibilité de définirvia une directive ou un fichier de configuration la ou les adresses qui devront être utilisées pour accéder auxservices web utilisés par votre code respectivement en environnement de test et en environnement de production.
  22. 22. Le réseau ralentit toujours les testsCependant, cette solution présente toujours des inconvénients, et plus particulièrement dans le cadre de testsunitaires.En effet, elle nécessite toujours laccès à un réseau qui peut ne pas être opérationnel ou accessible au moment delexécution de vos tests, par exemple parce que vous faites du développement piloté par les tests sur votreordinateur portable dans le train qui vous emmène au PHP Tour et que vous ne disposez pas dune clef 3G ou duVPN ad hoc pour vous connecter à votre infrastructure.
  23. 23. Le réseau ralentit toujours les testsDe plus, cela ne règle pas totalement le problème posé par la perte de performance de vos tests induite par lalatence du réseau.Or, un test unitaire peut être exécuté très souvent, parfois même plusieurs fois par minutes, surtout lorsque lonfait du développement piloté par les tests.La moindre perte de temps à ce niveau implique donc une perte de productivité, et à contrario, le moindre gain detemps entraîne une augmentation de productivité.
  24. 24. Installer un proxy nest pas forcément évidentCertes, pour contourner le problème, vous pourriez installer et configurer le logiciel nécessaire sur votre poste detravail, mais cela suppose que vous disposiez à la fois des compétences, des droits dadministration nécessaires,de léventuelle licence adéquate et du temps nécessaire pour le faire.Or, ce nest pas forcément le cas et dautant plus si le logiciel que vous utilisez en tant que proxy est payant.La solution consiste donc à ne pas du tout utiliser le réseau lors des tests unitaires et à utiliser en remplacementdes adapteurs ou des bouchons.
  25. 25. Je vais donc maintenant vous présenter deux cas pratiques dutilisation de ces deux outils en mappuyant suratoum, le framework de test unitaire que je développe, car il en dispose en standard et permet de plus de lesmettre en œuvre très rapidement et facilement.
  26. 26. LadapteurUn adapteur est un objet qui joue le rôle de proxy entre une fonction native du langage et votre code.En clair, lorsque vous utiliserez un adapteur dans votre code, lorsque ce dernier fera appel à une fonction nativedu langage, cet appel sera intercepté par ladapteur.Ce dernier décidera alors, en fonction de sa configuration, sil doit effectivement exécuter la fonction cible et enretourner le résultat ou au contraire retourner une valeur arbitraire.Cet outil est donc très utile dans le cas ou vous accéder à un service web à laide dune fonction PHP telle quefile_get_contents() ou encore à laide de lextension CURL, puisque cette dernière ne dispose pas dune interfaceobjet.
  27. 27. Les mockSi ladapteur permet de surcharger les fonctions natives de PHP, le mock permet quand à lui de simuler uneinstance dune classe spécifique, que cette dernière soit spécifique à lutilisateur ou bien créée par le développeur.Tout comme ladapteur, il permet de définir le comportement que doit la ou les méthodes appelées par linstance.Cet outil est donc très utile dans le cas ou vous accéder à un service web via une classe comme soapClient, parexemple.
  28. 28. Ce n’est pas une recette magique !Ladapteur et les mocks sont donc des outils puissants qui permettent au développeur de sabstraire des servicesweb dans le cadre de ses tests.Pour autant, ils ne sont pas une solution miracle à tout les problèmes, et en conséquence, les tests unitaires qui lesutilisent devraient toujours être complétés par des tests dintégration, des tests fonctionnels ainsi que par des testsmanuels, afin davoir une couverture du code la plus exhaustive possible.En effet, les différents types de test sont complémentaires et se recouvrent mutuellement.En conséquence, cest une erreur de croire que se contenter uniquement de tests unitaires ou de tests fonctionnelspermet de garantir que tous les comportements possibles du code ont été testés et quil ne reste pas des erreurs.De plus, même si atoum est conçu pour simplifier au maximum leur mise en œuvre et la maintenance des testscorrespondants, lutilisation de ces outils apporte une couche de complexité supplémentaire et il faut donc lesutiliser à bon escient, en fonction de leur valeur ajoutée.Ainsi, il ne sera peut être pas forcément pertinent et donc rentable dinvestir le temps nécessaire à la mise en placedadapteur et de mocks dans vos tests si vos services web sont suffisamment fiables et performants à vos yeux.

×