Cet article fait partie d’une série. Retrouvez tous les liens sur la page de sommaire.
Intro
Que l’on travaille dans une équipe de développement Front, sur la mise en place de services métier ou bien dans une équipe de testing, les premiers contacts avec une application se font souvent à travers de son interface graphique puis de son API.

Développée par Eviware, puis rachetée par SmartBear, SoapUI est une application OpenSource permettant de tester des appels de services web, l’automatisation de suite de tests et bien plus. Une version gratuite est disponible pour tous (c’est celle que j’utilise), la version payante ReadyAPI est bien plus complète, avec beaucoup d’écrans et de wizards pour faciliter la création de suites de tests.
Quand j’arrive sur un nouveau projet, mon premier réflexe est souvent de récupérer les points d’entrée de l’API et de tester. Très vite, on va pouvoir manipuler l’API, capitaliser et surtout créer une documentation vivante, à la fois pour moi, pour l’équipe et pour l’extérieur.
Avec qui ?
Par contre il ne faut pas se mentir, utiliser SoapUI c’est clivant ! Adulé ou détesté, chaque développeur ou testeur devra se faire un avis. Développé en Java, hyper consommateur en mémoire, difficile à mettre à jour… On reprendra ces arguments dans les prochains articles
Avant de se lancer sur un premier projet de test, la question se pose souvent “Pourquoi utiliser SoapUI ? Je peux tout faire avec Postman !”
Sans rentrer dans un débat, voici les gros avantages qui me font pencher pour SoapUI (je vous laisse vous faire votre propre avis ) :
- L’utilisation de scripts Java et Groovy
- L’import de librairies
- Pas uniquement du protocole REST (même si aujourd’hui je l’utilise presque exclusivement pour du REST ^^)
- Les plugins Maven et JUnit
Un premier projet
Sans refaire tous les tutoriels que vous pourrez trouver en ligne, on va tout de même initier un nouveau projet. Pour faire simple et tester rapidement une API existante, je vais me baser sur l’API Petstore.
- Il s’agit d’une API ouverte que chacun peut tester, avec un Swagger disponible : https://petstore.swagger.io/
- Le point d’entrée (Endpoint) : https://petstore.swagger.io/v2
- Une ressource pour tester : /pet/findByStatus
- Un paramètre à passer à la requête : status=available
On va donc créer un nouveau projet > utiliser l’URI d’une ressource GET “FindByStatus” > Exécuter la première requête.
Bon, là, c’est simple !!
On va pouvoir commencer à complexifier un peu, et jouer avec des cas un peu plus représentatifs de notre quotidien.
Dans les images ci-dessous, quelques ajouts ont été faits :
- Ajout des ressources “Pet” et “Store”
- Ajout des ressources filles “findByStatus”, “getById”, “inventory”, “post Order”, “Get Order”
- Renommer les méthodes par le verbe HTTP associé (GET, POST, DELETE, etc.)
- Renommer les requêtes (pour ne pas avoir Method1>Request1 pour toutes nos fenêtres ouvertes…)
- Appliquer tout de suite un premier niveau de paramétrage :
- Les paramètres de style “QUERY” sont ajoutés en fin d’URI, par exemple pour https://petstore.swagger.io/v2/pet/findByStatus?status=available
- Les paramètres de style “TEMPLATE” sont remplacés dans l’URI par la valeur, par exemple : https://petstore.swagger.io/v2/pet/9223318163395172212
Dernière étape pour aujourd’hui, on va créer une première suite de tests. L’intérêt des suites de tests est de pouvoir chaîner les appels, utiliser des assertions pour vérifier les résultats obtenus et bien plus. C’est le cœur de SoapUI, on y reviendra dans tous les prochains articles.
Ici on a donc une suite de tests qui enchaîne simplement nos deux appels REST, sans aucun contrôle. L’intérêt est donc limité Pour la création des étapes en revanche on voit tout de suite à quoi à servi le renommage des méthodes et des requêtes : c’est bien plus facile de s’y retrouver. Pensez à vous plus tard, quand vous aurez un projet avec beaucoup de points d’entrées et de requêtes différentes.
Pour les plus curieux, le projet est disponible sur GitHub sur le lien suivant : projet SoapUI_assets : 01-INTRO_Petstore-Project-soapui-project.xml
Dans la série d’articles à venir, je présenterai les fonctionnalités essentielles pour apprendre à utiliser SoapUI, optimiser son usage dans vos équipes, et quelques tips pour aller plus loin. On se concentrera sur les API REST sauf si vraiment vous insistez lourdement pour avoir des articles à base de Soap, de validation XSD et d’assertions XPATH
Je mettrai à jour l’index après chaque sortie d’un nouvel article de la série.
Bonne découverte !!
[…] Part 1 – Commencer avec SoapUI […]
Très utilisé et pratique pour de la supervision de prod également 🙂
Absolument !! On verra dans les articles sur le scripting et les automatisations quelques exemples, éventuellement à enrichir avec tes expériences David 🙂