Test de clients pour les services Web publics

Question

Quelles sont les approches pour tester des clients personnalisés pour des services Web publics?

Aujourd'hui, il existe de nombreux services en ligne qui fournissent une API. Il y a un boom de petites applications utilisant ces API. Exemples: clients de bureau/mobiles pour réseaux sociaux et plates-formes de blogging, centres de stockage et de traitement de documents, bases de données cloud, flux de données en temps réel, données SIG, etc ...

Le problème est souvent que la partie non triviale de ces applications est communiquer avec le service en ligne (gestion des erreurs, encodage/décodage des données, gestion des quotas, ajustement aux mises à jour de l'API, etc.), mais les développeurs du client ne contrôlent pas le service. On ne peut donc pas voir directement quels sont les effets des tests, et on ne peut pas toujours ramener l'état du service à l'original. Comment concevez-vous vos tests client pour être reproductibles?

• quels comportements testez-vous?
• Comment testez-vous les comportements destructeurs ou à forte charge? (par rapport à un service public)
• Exécutez-vous ces tests automatiquement (par exemple, en tant que hook de pré-validation)?
• Comment faites-vous des tests dans des situations extraordinaires (du service est en train de dépasser le quota, à l'état incohérent, au changement soudain de comportement du service)?

Answer 1

Soyez très clair sur ce que vous testez. Testez-vous que votre code fait ce qu'il est censé faire lorsqu'il reçoit des réponses du service? À la fois normal et extraordinaire? Puis se moquer du service, de sorte que vous pouvez facilement exercer ces chemins.

Oui Je voudrais concevoir des tests reproductibles et les exécuter sous un certain cadre qui me permet de les exécuter automatiquement, idéalement dans le cadre d'un build/commit aussi.

Mais qu'en est-il du test du service lui-même? Certains tests viennent juste de valider votre solution. Par exemple, une charge lourde. Eh bien, même s'il est important de ne pas être antisocial et qu'il n'est pas raisonnable de saturer un service public, s'il y a un SLA publié, alors je pense qu'il est raisonnable de le tester. Donc, si votre application est censée émettre n demandes une seconde, alors sûrement nous devrions tester au moins cela. Tester notre solution globale jusqu'à son débit requis.

À la destruction? Peut-être trop anti-social. Cependant, je pense que l'envoi de demandes valides et non valides et la vérification des réponses attendues peuvent être valides et valables si ce n'est que pour vérifier le service que vous utilisez. J'aurais donc au moins une suite de régression pour la fonction publique, de sorte que je puisse facilement confirmer qu'elle se comporte comme elle est documentée.