Les API doivent fonctionner correctement, l’avenir de l’entreprise en dépend : il est donc vital de les tester soigneusement, prévient Yves de Montcheuil, Revenue Godfather de Restlet, fournisseur d’une plateforme permettant aux entreprises de piloter leur transformation numérique grâce aux API.
Les API sont devenues le nouveau middleware. Elles permettent entre autres :
- à des applications frontales de se connecter à des systèmes backend ;
- à des objets connectés et à des capteurs de communiquer avec des services cloud ;
- à des applications d’interagir…
D’abord utilisées principalement en interne, les API se sont émancipées et jouent un rôle clé dans l’interaction avec les clients ou les partenaires. Les API entrent ainsi dans le cadre d’un processus métier existant ou constituent une activité à part entière.
C’est une réalité indéniable : désormais les entreprises dépendent de plus en plus des API. Pourtant, contrairement à la plupart des applications métiers critiques, leur développement est rarement industrialisé comme celui des logiciels modernes. Il s’agit là d’une erreur stratégique à laquelle il est indispensable de remédier rapidement.
Les API sont la partie immergée de l’iceberg
Contrairement à un site Web ou à une application mobile proposant une présentation soignée, les API sont invisibles aux yeux des utilisateurs. Elles sont donc examinées en dernier, généralement trop tard, au moment où un problème d’ordre critique surgit et prend les parties prenantes au dépourvu.
La détection de réponses erronées ou la confirmation du traitement adéquat des conditions d’erreur ne peuvent pas toujours être gérées lors des tests d’interface utilisateur. En effet, parfois, le domaine de paramètres issus de l’application ne déclenche pas certains scénarios prévus. Dans d’autres cas, les conditions d’erreur retournées par l’API ne sont pas notifiées par l’application ; cette dernière affiche à la place un message d’attente frustrant tandis qu’elle retente un appel.
Comme pour toute pile logicielle, chaque couche doit être testée indépendamment. Les API n’ayant pas d’interface utilisateur, elles doivent être testées à l’aide d’appels imitant le comportement des applications.
Utiliser le contrat d’API : une approche simple
Les API REST suivent des principes et concepts architecturaux standardisés, ce qui leur permet d’avoir un comportement prévisible. Chaque API possède un contrat (les plus célèbres langages de contrat d’API étant Swagger, RAML et API Blueprint), qui décrit l’ensemble des méthodes pouvant être invoquées, les paramètres transmis et les résultats attendus.
Il est très facile d’invoquer une API, car son URI est lisible par tout un chacun, tout comme ses formats de charges utiles (JSON ou XML par exemple). Il existe également des outils qui simplifient grandement ce processus en évitant de saisir toutes ces invocations manuellement. Certains proposent une interface en ligne de commande tandis que d’autres proposent une interface utilisateur plus sophistiquée pour la configuration et la liaison entre les appels.
Intégrer les API à votre chaîne de compilation de logiciels
Tester une API ne se résume pas à essayer quelques appels et à vérifier que les valeurs obtenues sont celles prévues. En effet, l’automatisation de la qualité s’applique également aux API comme au reste de la pile logicielle.
Les appels d’API doivent donc être regroupés dans des scénarios de test à part entière qui seront exécutés à chaque fois qu’une nouvelle version est créée ou déployée. Il est nécessaire d’ajouter les tests d’API à la chaîne de compilation et d’intégration/livraison continue de logiciels (conçue avec Jenkins ou Bamboo, par exemple). En effet, la plupart des outils mentionnés prennent en charge cette fonctionnalité, avec des niveaux d’automatisation divers.
