Beaucoup utilisent SoapUI pour tester à la fois l'API elle-même et les applications qui accèdent à l'API. Un outil assez flexible qui permet, par exemple, d'exporter un
fichier API swagger et de générer un service Mock basé sur celui-ci.
Il n'y a pas si longtemps, dans notre entreprise, j'ai été confronté à un problème similaire, mais avec des conditions non triviales. Données initiales: il est nécessaire de tester une application serveur qui reçoit une tâche en entrée; pendant l'exécution, elle se réfère à l'API; chaque demande ultérieure dépend de la réponse de l'API. La logique est intégrée dans l'application. Autrement dit, une sorte de boîte noire où vous devez tester de nombreuses sorties du script, lorsqu'il n'y a qu'une seule entrée dans le script.
Ci-dessous, je propose un exemple de solution qui a permis de l'intégrer facilement dans l'infrastructure de régression, ainsi que d'avoir une marge de mise à l'échelle, dans le cas d'une augmentation de la couverture de l'éventail des scénarios et de leur complexité.
Tout d'abord, créez un service Mock dans SoapUI. Cela se fait en quelques clics:
Passons maintenant à la création de talons pour les requêtes. Puisqu'il n'y a qu'une seule entrée dans le script dans la tâche, nous avons des options:
- utiliser l'identifiant du script et le transmettre dans chaque requête, et dans chaque talon déterminer la réponse en fonction de cet identifiant;
- spécifiez à l'avance une liste de réponses pour chaque talon et stockez-les dans des variables globales avant d'exécuter le test.
La première option peut être utilisée lorsqu'il est nécessaire de recevoir une réponse du stub pour plusieurs demandes en même temps. L'implémentation nécessite que l'application cliente puisse transmettre un identifiant spécifique dans chaque requête d'API. Dans notre cas, cela était pratiquement impossible, et le test simultané de plusieurs scénarios n'était pas nécessaire, donc la deuxième option a été choisie.
Ainsi, pour attribuer une liste de réponses de stub, nous exécutons la requête suivante avant d'exécuter le test:
Post: http:
Dans le service Mock, nous ajoutons le traitement de demande «SetScenario». Il n'a que deux réponses: «200_OK» si la demande entrante a été traitée correctement, et «400_BadRequest» si la demande a été faite incorrectement:
Dans le script, nous distribuons les valeurs de réponse pour les stubs globaux pour chaque stub:
def reqBody = mockRequest.getRequestContent() // def reqBodyParams = [:] reqBody.tokenize("&").each // , { param-> def keyAndValue = param.split("=") reqBodyParams[keyAndValue[0]]=keyAndValue[1] } if (reqBodyParams.containsKey('ScenarioId')) // ID ( ); { // , , “?:” – : context.mockService.setPropertyValue("ScenarioId", reqBodyParams["ScenarioId"] ?: "0") context.mockService.setPropertyValue("Authentication", reqBodyParams["Authentication"] ?: "200_OK") context.mockService.setPropertyValue("AutoSystemHome", reqBodyParams["AutoSystemHome"] ?: "200_OK") // … return "200_OK" } else { return "400_BadRequest" }
Les variables attribuées sont visibles dans la fenêtre des paramètres de service:
Ainsi, nous décrivons toute la logique du service Mock dans cette méthode, et dans les talons des méthodes API, il suffit d'écrire un script qui lit la valeur de réponse de la variable globale:
Authentication = context.mockService.getPropertyValue("Authentication") return "${Authentication}"
AutoSystemHome = context.mockService.getPropertyValue("AutoSystemHome") return "${AutoSystemHome}"
Si vous devez ajouter des scripts de délai d'expiration, des réponses différées, puis ajoutez la variable de délai, par exemple:
Post: http://mockserver:8080/setscenario Body: ScenarioId=0&Delay=600&Authentication=200_OK &AutoSystemHome=400_TokenIsMissing…
Et dans le script stub, nous ajoutons:
… Authentication = context.mockService.getPropertyValue("Authentication") Delay = context.mockService.getPropertyValue("Delay").toInteger() sleep(Delay) return "${Authentication}"
S'il est nécessaire de soutenir la demande répétée, nous transférons la liste des réponses:
Body: Authentication:400_MissingParametersClientId;400_MissingParametersClientId;200_OK
Et dans le script de traitement, ajoutez tokenize et supprimez la réponse déjà envoyée, si ce n'est pas la dernière:
def Authentication = [] Authentication = context.mockService.getPropertyValue("Authentication").tokenize("%3B") if (Authentication.size() > 1) { Authentication.remove(0) Authentication = Authentication.join("%3B") context.mockService.setPropertyValue("Authentication", Authentication) }
En conséquence, nous avons obtenu un service Mock simple, qui est facile à déplacer entre les bancs de test et les environnements, car le fichier de projet est un fichier xml. Le service démarre immédiatement après l'importation, sans paramètres supplémentaires (sauf pour changer l'adresse du serveur et le port, bien sûr). Pour le moment, il nous aide à tester l'application indépendamment de la stabilité du serveur IPA et des périodes possibles de son inaccessibilité.
Ce que nous prévoyons d'ajouter: intégrer cette solution pour tester les applications avant et pendant le développement de l'API elle-même. Par exemple, lorsque sa description est déjà prête sous la forme d'un fichier swagger, mais que le serveur est en cours de configuration. Les cycles de développement des API et des applications clientes ne coïncident pas toujours. À ce stade, il est utile de tester l'application client en cours de développement pour quelque chose, et le service Mock peut beaucoup aider.
UPD: au cas où vous auriez des questions et des commentaires utiles.