Vaut-il vraiment la peine de tester un client API?
C'est quelque chose qui me préoccupe depuis un moment maintenant. Vaut-il vraiment la peine de tester un client API?
Supposons que vous créez une petite classe pour résumer les appels à un petshop REST. Le petshop est une API très simple et possède un ensemble de méthodes de base:
listProducts()getProductDetails(ProductID)addProduct(...)removeProduct(ProductID)
Pour tester cela, nous devons créer un service factice ou simuler les réponses. Mais cela semble exagéré; Je comprends que nous voulons nous assurer que nos méthodes ne cessent pas de fonctionner à travers des erreurs de typo/syntaxe, mais comme nous écrivons des fonctions qui appellent des méthodes distantes et que nous créons ensuite de fausses réponses à partir de ces méthodes distantes, il semble que un gaspillage d'efforts et que nous testons quelque chose qui ne peut pas vraiment échouer. Pire encore, si la méthode à distance change, nos tests unitaires passeront alors que l'utilisation en production échouera.
Je suis presque sûr qu'il me manque quelque chose, ou j'ai la mauvaise extrémité du bâton, ou je ne vois pas le bois pour les arbres. Quelqu'un peut-il me mettre sur la bonne voie?
Le travail d'un client API distant consiste à émettre certains appels - ni plus, ni moins. Par conséquent, son test doit vérifier qu'il émet ces appels - ni plus, ni moins.
Bien sûr, si le fournisseur d'API modifie la sémantique de ses réponses, votre système échouera en production. Mais ce n'est pas la faute de votre classe client; c'est quelque chose qui ne peut être détecté que dans les tests d'intégration. En vous appuyant sur un code qui n'est pas sous votre contrôle, vous avez abandonné la possibilité de vérifier l'exactitude via des tests internes - c'était un compromis, et c'est le prix.
Cela dit, tester une classe qui ne comprend que des délégations à une autre classe peut être de faible priorité, car il y a relativement peu de risques d'erreurs complexes. Mais cela vaut pour toute classe qui se compose uniquement de uniformes uniformes, cela n'a rien à voir avec l'appel dans le code d'un autre fournisseur.
Réponse courte:
Toutes les méthodes doivent être testées à l'unité.
Réponse longue:
Oui. Ça vaut le coup.
Voici quelques éléments que les tests unitaires sur ces méthodes appelant l'API devraient tester:
- Que vous transmettez des paramètres corrects ou corrects aux appels d'API.
- Que vous répondez en conséquence à certains types de données renvoyées par les API (moquées ou non), par exemple peut-être lorsque l'API renvoie une chaîne vide, votre méthode doit renvoyer une valeur par défaut (juste un exemple)
- Que les méthodes d'appelant se comportent correctement lorsque les appels d'API produisent une erreur
Ce sont des choses que la méthode appelée fait qui peuvent être isolées en se moquant du service API, et qu'en les testant bien, vous assurer que les erreurs ne proviennent pas d'une erreur dans le code client qui appelle l'API.
Il ne s'agit pas de tests unitaires car vous testez les entrées et les sorties de votre système, plus comme des tests d'intégration limités.
Soyez très prudent lorsque vous dites "cela semble être une perte d'effort et que nous testons quelque chose qui ne peut pas vraiment échouer" - cela peut échouera, il échouera, il échouera probablement d'une manière que vous ne pouvez pas prévoir, les échecs seront pires si vous n'avez pas de tests en place.
L'erreur que vous faites ici est liée à l'invention des roues: effectuer des appels vers des services distants et des API est un scénario très courant, il existe donc de très bons outils pour vous aider à tester cela. La dernière fois que je travaillais sur une application qui se connectait à des services distants, j'ai utilisé SoapUI qui pouvait regarder un service et faire des appels simulés à ce service ou se comporter comme une copie locale du serveur que vous pouvez faire tester les appels et suivre les demandes et les réponses. La configuration a pris quelques minutes et a également été très rapide à mettre à jour si l'interface à distance avait changé. Je ne l'ai pas utilisé dans un scénario REST, mais même si cela ne fonctionne pas bien pour cela (ou peut-être que quelqu'un lira cette réponse à l'avenir alors que de meilleurs outils existent), vous devriez être capable de trouver un outil qui peut simuler un service pour vous et quand vient le temps de déployer votre code, vous serez heureux de l'avoir fait.