Bien souvent, le bon fonctionnement de notre application métier est couverte par des tests unitaires. Cependant, lorsqu’on travaille sur un projet web, il n’est pas évident de vérifier le comportement des web services que l’on expose. Dans cet article je vais vous présenter SoapUI. Développé par SmartBear Software, cette application Java open source sous licence EUPL permet de manipuler des requêtes SOAP et REST allant de la simple injection de requête jusqu’à la mise en place de tests de charge.
Capitaliser ses requêtes
Une des principales fonctions de SoapUI est de pouvoir capitaliser ses requêtes SOAP afin de mettre en place une bibliothèque et ainsi retrouver et rejouer facilement une requête donnée afin de tester le comportement de son application. Pour se faire, il suffit de créer un nouveau projet pour lequel on fourni le contrat décrivant notre service. Ce contrat peut avoir plusieurs formes WSDL pour du SOAP, ou WASDL (voire l’URI de la requête) pour du REST.
Une fois la description du contrat fournie (ex : http://localhost:64833/WebService.asmx?wsdl), l’application va être capable de proposer l’ensemble des requêtes qui y sont décrites. A la charge de chaque développeur d’y ajouter leurs requêtes pour les rejouer. Le format de sauvegarde étant du XML, il est facile de le partager en le versionant sous Git par exemple.
Tester son application
TestCase : cas d’utilisations
Une fois que l’application cible fonctionne et qu’elle semble répondre correctement, il est pratique de pouvoir vérifier si son comportement est en phase avec les besoins fonctionnels exprimés par le client. Pour cela, SoapUI donne la possibilité de regrouper et chainer des requêtes sous forme de TestCases. Cela permet ainsi de modéliser par exemple les différents cas de connexion comme “Connexion valide”, “Connexion avec mauvais identifiant”, “Multiple tentatives de connexion”, …
Step
Un TestCase se compose d’un enchainement d’étapes, appelés Steps, qui peuvent prendre plusieurs formes :
- Exécuter une requête (SOAP, REST, HTTP, JDBC, …) créée spécialement pour le test ou extraite de notre bibliothèque de tests
- Définir des variables et de les propager entre les tests
- De faire appel à d’autres TestCase
- D’exécuter du Groovy Script
- De se comporter en tant que serveur pour mocker une réponse
Un des steps qui mérite d’être cité, c’est « JDBC Request », il permet de se connecter à une base de données et d’exécuter une requête SQL. Cela peut s’avérer pratique dans les cas où l’on s’attend à la création d’une entité, que la réponse du web service semble valide mais qu’aucune création n’a été faite en base.
Pour chaque Step de type « Request » il est possible de préciser une liste d’assertions permettant de spécifier les attentes de la réponse. Si toutes les assertions sont satisfaites, alors l’étape suivante est exécutée, autrement le TestCase est invalidé. On peut alors contrôler la présence d’une chaine de caractère, vérifier le statut de la requête (200, 403, 404, 418, …) ou bien que la réponse satisfait le contrat du service
TestSuite : campagne de tests
Les TestSuites peuvent s’apparenter à des campagnes de tests. Ils permettent de choisir les cas fonctionnels (TestCases) et cibler le domaine fonctionnel que l’on souhaite tester.
Conclusion
SoapUI est un outil à la frontière entre technicité et fonctionnel permettant de faire travailler conjointement les développeurs avec les spécificateurs. Pour ma part, j’ai eu l’occasion de l’utiliser lors d’une précédente mission durant laquelle nous exposions des web services via une application ASP .NET. De pair avec les équipes fonctionnelles, nous mettions en places des tests de non régression via SoapUI afin d’automatiser les campagnes de tests.
