Ce que SoapUI fait toujours bien
SOAP et WSDL. Une prise en charge vraiment de premier ordre, là où la plupart des outils modernes la traitent comme un ajout secondaire, quand ils la traitent.
Construction de messages complexes. Manipulation et assertions XML en profondeur, exactement ce dont l'intégration d'entreprise a besoin.
Services simulés. De quoi monter un endpoint factice pour développer, directement intégré.
Si votre travail repose largement sur SOAP, mesurez bien ce que vous abandonneriez. La portée est réelle.
Pourquoi les équipes cherchent malgré tout
| Un flux de travail taillé pour le poste de travail | Des fichiers de projet qui vivent sur la machine de quelqu'un et se relisent mal. Les modifications sont difficiles à attribuer dans une pull request. |
| Frictions avec le pipeline | L'exécution headless est possible, rarement agréable. Les rapports n'arrivent pas là où arrivent ceux du reste de la CI. |
| L'ergonomie REST | Le modèle a été conçu pour SOAP. REST fonctionne, mais donne l'impression d'avoir été rapporté. |
Sur quoi comparer une alternative à SoapUI
| Critère | SoapUI | TestSprite |
|---|---|---|
| Portée des protocoles | SOAP, WSDL, REST, JMS et d'autres | API REST contre le service en cours d'exécution |
| Où vivent les tests | Des fichiers de projet, édités dans un client de bureau | Dans le projet, décrits en langage naturel |
| Comment la couverture se construit | Quelqu'un construit chaque requête et chaque assertion | Générée à partir d'une spécification ou d'une passe de découverte |
| Session et état | Des propriétés et des scripts que vous maintenez | Auto-Authentication et Dynamic Variables |
| Ordonnancement et nettoyage | L'ordre des cas de test, plus des scripts de teardown | Un ordonnancement déduit et Auto-Cleanup |
| Intégration au pipeline | Exécuteur headless, rapports séparés | Déclenché par la modification, résultats sur la pull request |
Les mécanismes de la gestion de l'état se trouvent dans la documentation sur les tests d'API.
La vérification à faire avant de migrer
Faites l'inventaire de ce qui relève vraiment de SOAP. Les équipes découvrent souvent que la suite est à quatre-vingt-dix pour cent du REST, avec une poignée d'endpoints SOAP hérités que personne n'a touchés depuis des années. Si c'est votre cas, la migration est bien plus réduite qu'il n'y paraît, et le SOAP restant peut rester où il est.
Si la suite repose vraiment sur SOAP, ne migrez pas pour des raisons d'ergonomie. La portée compte davantage.
Comment évaluer n'importe lequel de ces outils
Cassez quelque chose volontairement. Introduisez une vraie régression, par exemple un enregistrement qui ne persiste plus, et regardez ce que chaque candidat remonte. Le test échoue-t-il, l'échec nomme-t-il la divergence réelle, et la personne chargée du correctif peut-elle partir de cette sortie sans reconstituer toute l'histoire. Un outil qui annonce un succès sur une exécution qui n'a jamais atteint ses assertions a échoué au seul test qui compte.
Découper la suite avant de migrer
La migration qui fonctionne ne se fait presque jamais d'un seul coup, et le découpage est plus simple qu'il n'y paraît, parce que SOAP et REST s'entremêlent rarement dans un même test.
Commencez par étiqueter chaque cas de test par protocole. La plupart des équipes obtiennent trois groupes : du vrai SOAP contre des services hérités, du REST contre des services plus récents, et une poignée de cas qui touchent aux deux parce qu'un flux traverse les générations. Le premier groupe reste où il est et cesse d'être une raison de garder toute la suite au même endroit. Le deuxième migre. Le troisième mérite un examen au cas par cas, et se scinde souvent en deux tests qui avaient été fusionnés par commodité plutôt que par nécessité.
Faire cet étiquetage d'abord donne à la migration une fin visible, ce qui fait toute la différence entre un projet qui se termine et un projet encore à moitié fait un an plus tard.
Pour commencer
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Si vous préférez ne rien installer, le tableau de bord fait la même chose. Tout ce que la ligne de commande sait faire par ailleurs se trouve dans le dépôt du CLI.
La GitHub App est un webhook que vous configurez dans le tableau de bord TestSprite. Il écoute l'événement de déploiement que votre pipeline produit déjà, si bien que rien ne change dans votre dépôt.
GitHub Actions place l'étape à l'intérieur de votre propre workflow, configurée depuis le terminal.
Ce que TestSprite couvre côté REST
Tout ce que faisait la partie REST de votre suite, avec un flux de travail adapté à un pipeline plutôt qu'à un poste de travail. Les cas vivent dans le projet, sont décrits en langage naturel et s'affinent de la même manière : une modification devient donc quelque chose qu'une deuxième personne peut relire.
La gestion de l'état est fournie par le produit : Auto-Authentication, Dynamic Variables, Dependency Chains et Auto-Cleanup, là où SoapUI vous laisse maintenir des propriétés, des étapes de transfert, l'ordre des cas de test et des scripts de teardown.
Les exécutions sont déclenchées par votre déploiement ou depuis votre propre workflow, et les résultats arrivent sous forme de commentaire sur la pull request. Votre travail SOAP reste là où il est correctement pris en charge, et la migration a une fin visible au lieu d'être encore à moitié faite un an plus tard.
TestSprite prend-il en charge SOAP ?
L'accent est mis sur les API REST contre un service en cours d'exécution. Pour les suites très orientées SOAP, conservez ce qui gère correctement SOAP et utilisez TestSprite pour la surface REST.
Pouvons-nous convertir des projets SoapUI ?
Servez-vous-en comme d'un inventaire de l'existant plutôt que comme de quelque chose à convertir. La liste des endpoints et les assertions auxquelles les équipes tenaient sont le contenu qui a de la valeur.
Et les services simulés ?
C'est une capacité distincte, à conserver si vous en dépendez. Simuler et vérifier sont deux métiers différents.
Vaut-il mieux passer à Pro plutôt que de changer d'outil ?
Si le reproche porte sur les fonctionnalités, peut-être. Si le reproche est que le flux de travail ne s'adapte pas à un pipeline, un niveau de licence n'y changera rien.
Comment faire tourner les deux pendant une transition ?
Pointez-les vers des parties différentes de la surface et lancez-les tous les deux depuis la CI. Rien n'oblige à basculer en une seule fois.
Vérifiez quelle part de votre suite relève réellement de SOAP.
Une alternative à SoapUI a du sens quand le flux de travail taillé pour le poste de travail ne correspond plus à votre pipeline, et la plupart des suites se révèlent majoritairement REST. Gardez SoapUI pour le vrai travail SOAP, et déplacez la surface REST vers un outil adapté à votre façon de livrer.