Les bibliothèques clientes Google Cloud pour Rust fournissent des assistants qui simplifient l'interaction avec les opérations de longue durée (LRO). Pour simuler le comportement des LRO dans les tests unitaires, il faut comprendre les détails sous-jacents que ces assistants masquent. Ce guide vous explique comment écrire des tests unitaires pour l'interrogation automatique et manuelle des LRO, y compris pour les scénarios d'erreur.
Prérequis
Ce guide part du principe que vous connaissez les guides suivants :
Tester la détection automatique
Supposons que le code de votre application attende lro::Poller::until_done() (interrogation automatique) :
Étant donné que l'application n'utilise que le résultat final de l'opération de longue durée, vous n'avez pas besoin de tester la façon dont elle gère les résultats d'interrogation intermédiaires. Votre test peut renvoyer le résultat final de la LRO directement à partir du simulacre.
Créer le longrunning::model::Operation
Supposons que vous souhaitiez que l'appel renvoie la réponse suivante :
Le bouchon renvoie un longrunning::model::Operation plutôt qu'un BatchRecognizeResponse. Empaquetez la réponse attendue dans Operation::result :
Définissez le champ done sur true pour indiquer à Poller que l'opération est terminée, ce qui met fin à la boucle d'interrogation :
Écrire le test
Définissez la structure fictive, qui implémente le trait
speech::stub::Speech:Dans le test, créez le simulacre et définissez les attentes correspondantes :
Créez un client à partir du simulacre, appelez la fonction et vérifiez la réponse :
Tester l'interrogation manuelle avec des métadonnées intermédiaires
Supposons que le code de votre application interroge manuellement et traite les mises à jour partielles :
Vous pouvez simuler le comportement de l'application lorsqu'elle reçoit des métadonnées intermédiaires en renvoyant des opérations en cours à partir du simulacre.
Créer le longrunning::model::Operation
Le RPC BatchRecognize renvoie des résultats partiels sous la forme d'un speech::model::OperationMetadata. Empaquetez ces métadonnées dans le champ Operation::metadata de l'élément longrunning::model::Operation renvoyé :
Écrire le test
Définissez la structure fictive, qui implémente le trait
speech::stub::Speechet remplaceget_operation():Dans le test, créez le simulacre et définissez des attentes pour qu'il renvoie des résultats partiels (25 %, 50 %, 75 %), suivis du résultat final :
Notez les détails suivants sur la configuration des attentes :
- RPC initiales et ultérieures : la première attente est définie sur
batch_recognize(), tandis que toutes les attentes ultérieures sont définies surget_operation(). Le RPCBatchRecognizeinitial démarre l'opération de longue durée sur le serveur et renvoie un identifiant d'opération dans le champname(omis du code de test par souci de concision). À partir de ce moment, la bibliothèque cliente interroge l'état de cette LRO à l'aide du RPCGetOperation. - Ordre des appels : les attentes sont enregistrées dans un
Sequence. Cela permet àmockallde vérifier l'ordre des appels et de déterminer quelle attenteexpect_get_operationcorrespond à chaque interrogation.
- RPC initiales et ultérieures : la première attente est définie sur
Créez un client à partir du simulacre, appelez la fonction et vérifiez la réponse :
Simuler des erreurs
Des erreurs peuvent se produire à plusieurs moments au cours d'une LRO.
Si votre application utilise l'interrogation automatique, toutes les sources d'erreur sont équivalentes : until_done() renvoie l'erreur dans Result, quelle que soit son origine.
Simuler une erreur lors du démarrage d'une LRO produit le test le plus simple.
Simuler une erreur lors du démarrage d'une opération de longue durée
Pour simuler une erreur lors du démarrage d'une LRO, configurez la requête initiale pour qu'elle échoue avec une erreur :
Pour l'interrogation manuelle, la branche PollingResult::Completed reçoit l'erreur liée au démarrage de la LRO, ce qui met fin à la boucle d'interrogation :
Simuler une LRO entraînant une erreur
Pour simuler une LRO qui échoue après avoir renvoyé des métadonnées intermédiaires, renvoyez l'erreur dans le longrunning::model::Operation final :
Définissez les attentes pour renvoyer l'échec de Operation à partir de get_operation :
Dans l'interrogation manuelle, la branche PollingResult::Completed reçoit le résultat de l'erreur, ce qui met fin à la boucle d'interrogation :
Simuler une erreur d'interrogation
Les boucles d'interrogation peuvent également se terminer lorsque la règle d'interrogation est épuisée. Dans ce cas, la bibliothèque cliente ne peut pas déterminer de manière définitive si l'opération de longue durée est terminée.
Si votre application dispose d'une logique personnalisée pour gérer les erreurs d'interrogation, vous pouvez la tester en renvoyant une erreur directement à partir de l'attente get_operation :
Dans l'interrogation manuelle, la branche PollingResult::PollingError reçoit l'erreur d'interrogation simulée :
Code de test complet
Les sections suivantes présentent le code complet des tests décrits dans ce guide.