Comment faire des tests d'API externes (blackbox)

Supposons que vous utilisez des API d'un fournisseur, comment vous assurer que leur API fonctionne comme prévu?

Ma principale préoccupation est parfois que le fournisseur a poussé les modifications de son code et brisé l'API, nous voulons avoir une sorte de logiciel automatique pour les tester continuellement. Comment y faire face?

Réponse courte: vous avez besoin d'une suite de tests pour une API de fournisseur tiers - vous devrez donc en développer une.

Ne vous attendez pas à ce que quelqu'un d'autre le fasse pour vous, et ne vous attendez pas à une "balle magique" pour générer automatiquement les bons tests.

Certaines choses que vous pourriez essayer en plus:

• demandez au vendeur s'il fournit une liste des «changements de rupture» pour chaque nouvelle version
• demandez-leur comment ils se soucient de la compatibilité des API / informez-les que c'est une fonctionnalité importante pour vous
• vérifier si l'API fournit des crochets de test spécifiques, une sortie de journalisation ou quelque chose comme ça pour les pièces qui n'ont pas pu être testées facilement non plus
• envelopper les appels d'API importants avec votre propre code de journalisation, en écrivant l'entrée et la sortie associée de l'API dans un fichier journal, cela facilitera le débogage des choses si quelque chose d'inattendu se produit
• ajouter des assertions aux appels d'API pour vérifier les pré et postconditions, donc si une nouvelle version de l'API présente un comportement inattendu dans votre application, vous êtes informé tôt par un message d'erreur

Si ces choses fonctionnent ou non, cela dépend de qui est votre fournisseur et du type d'API que vous avez en tête. Une API qui produit une sortie inspectable comme des fichiers est beaucoup plus facile à tester qu'une API qui contrôle un périphérique physique où vous devez observer le comportement de la chose pour décider si l'appel d'API a réussi ou non.

Sur la base du libellé de l'affiche, c'est plus que des tests, IMO. Après avoir écrit votre test unitaire pour l'API et vous être assuré que tout fonctionne comme prévu, vous devez surveiller les API tierces afin de détecter les problèmes avant que les utilisateurs ne le fassent. C'est le vrai risque avec les API tierces - ce n'est pas votre code et vous n'avez aucun contrôle sur la quantité de tests effectués sur l'API ou quand / si elle change.

(Avertissement: noms de produits utilisés ici) Si vous utilisez soapUI pour écrire vos tests d'API, ces tests peuvent être réutilisés dans AlertSite en tant que moniteur opérationnel pour vous assurer que l'API continue de fonctionner comme prévu. S'il échoue au test, vous pouvez être alerté avant que vos utilisateurs ne vous appellent et se plaignent que votre application ne fonctionne pas.

Mettez en œuvre des tests d'apprentissage pour votre domaine d'intérêt (fonctionnalités que vous prévoyez d'utiliser). Les tests d'apprentissage sont des tests d'intégration qui sont écrits par le développeur contre le contrat public de l'API. Les tests ne doivent pas être écrits par rapport aux détails de l'implémentation interne même si le code source de l'API est disponible. Ce type de tests d'apprentissage sert à deux fins -

1. Il améliore considérablement votre compréhension de l'API tierce.
2. Les tests permettent de vérifier si la nouvelle version revendiquée est réellement rétrocompatible ou non.

Il existe 2 approches pour ce problème ...

votre application est en production avec un trafic utilisateur réel:

si vous avez une application en production qui a du trafic en direct et dépend d'une API externe, vous n'avez pas d'autre choix que de surveiller de près et d'avoir de bons seuils pour savoir aussi vite que possible lorsque l'API externe apporte des modifications sans en informer.

vous devez toujours tenir compte du fait que:

• le changement de l'API au fil du temps
• le vendeur d'api peut avoir des bugs
• Les kits de test des vendeurs d'API peuvent avoir des bugs ou ne pas couvrir entièrement toutes les fonctionnalités de l'API de production

votre application est une installation et a prévu des versions / versions:

dans ce cas, vous disposez d'un délai de grâce pour échouer ... l'utilisateur en direct n'est pas affecté immédiatement des modifications de rupture de l'api externe.

à mon avis, c'est une tâche plus facile. écrire un test (test complet de bout en bout) qui effectue des transactions / http / requêtes réelles pour votre application qui invoque l'api externe et vérifie qu'il n'y a pas d'échecs. pas de kits de test pas de transaction réelle simulée.

une fois cette tâche terminée, vous pouvez choisir de l'exécuter toutes les 24 heures, 1 minute, etc.

bonnes pratiques:

• automatiser tout
• avoir une personne que vous pouvez contacter rapidement auprès du vendeur de l'api externe
• ne faites pas aveuglément confiance au vendeur testez tout
• échouer rapidement - si votre service dépend fortement de l'API externe, ne laissez pas votre service planter. échouer rapidement et renvoyer les messages d'erreur appropriés

outils:

• surveillance de l'application en direct: nouvelle relique hyperique
• test API : apimetrics runscope soapui