Comment tester les API ?

Dès lors, la mise en œuvre des API⁽¹⁾ (Application Programing Interface) est une problématique fondamentale d’un projet. Elle est intégrée à chaque étape de projet, depuis le design de service jusqu’à la production technique, en passant par la conception fonctionnelle.

Si l’on considère leurs aspects techniques, les API nous intéressent dans cette série d’articles consacrés à la pratique des tests dans le projets digitaux. Dans cet article, j'aborde les questions du testing autour des problématiques spécifiques des API. Nous allons ainsi déterminer les enjeux propres aux API en posant leur « contexte » au sein d’un projet. Et je poursuivrai avec une démarche de tests des API ainsi que les outils utiles.

Qui sont les consommateurs et producteurs d’API ?

Les API présentent deux versants « d’utilisation » dans un projet digital. Selon deux « points de vue », on peut être « consommateur » d’une API, ou « producteur » d’une API.

Quand on consomme une API, l’application « cliente » est conçue et développée pour interagir avec une API dont on connait, a priori également, les possibilités de fournir telles données ou tels services. C’est ce que propose cette ou ces API qui guident la façon de la consommer. Les API proposent, les applications clientes disposent. L’enjeu pour l’application cliente, et surtout pour les développeurs qui la développent, c’est que le « contrat » passé avec l’API soit bien respecté. Autrement dit, que l’API utilisée réponde bien à la demande (à la requête http) avec les bonnes données, dans le bon ordre et dans le délai imparti. Ici, le développeur consommateur est attentif à la « sûreté » de fonctionnement de l’API. « Sûreté » qui recouvre conformité, fiabilité et performance. La propre sûreté de l’application cliente, envers ses utilisateurs finaux, est conditionnée par la sûreté de l’API qu’elle consomme. L’une de va pas sans l’autre.

Quand on produit une API, les enjeux sont de même nature. Il s’agit d’implémenter une API qui délivre de façon performante des données et des services conforment aux attentes des « consommateurs ». La sûreté de fonctionnement est donc au cœur du « contrat » qui lie les API à une ou plusieurs applications consommatrices. Lorsque ces API sont distribués à très grande échelle, commercialement ou non (dans le cas de l’open data), gratuitement ou non, les applications consommatrices peuvent être potentiellement très nombreuses. Dès lors, implémenter une API fiable et performante conditionne la crédibilité (et le modèle économique) souvent de l’entité qui propose son API aux « consommateurs ».

Producteurs et consommateurs d’API voient donc leur enjeux s’aligner : une API doit être fiable. En ingénierie logicielle, le test est toujours la bonne réponse à une problématique de fiabilité.

Comment réaliser les tests d’API ?

Lorsqu’on implémente une API (en tant que producteur de cette API) donc, le projet de développement ne fait pas exception aux pratiques de testing.

Puisqu’une API est un projet de développement comme les autres, les tests unitaires ont tout leur rôle à jouer dans la production du code technique et du code fonctionnel qui met en œuvre une API. Si vous n’êtes (toujours) pas convaincu par les tests unitaires, ou si vous rencontrez encore des difficultés à les comprendre, nous vous donnons ici quelques conseils de lecture : La vérité sur les tests unitaires.

Pour répondre au besoin de « sûreté » de fonctionnement, le test doit aussi se pratiquer à un plus « haut » niveau. Ici, la pratique rejoint celle du test d’acceptation (autre conseil de lecture : Les avantages du Test Driven Development) puisqu’il s’agit de savoir si l’API, point d’API après point d’API, répond bien à un « contrat » passé avec le consommateur de l’API. Il est question de savoir si l’API répond bien à la spécification « fonctionnelle » qu’on lui a attribué, en plus de répondre à une spécification technique selon son format (REST, JSON API, SOAP, etc.).

Dans une pratique très concrète, tester une API, techniquement et fonctionnellement, passe par un outil spécifique : un outil de documentation d’API digne de ce nom.

Cet outil permet de « documenter », ou encore mieux de « spécifier » une API à travers ses différents points d’API (endpoints). Une syntaxe (souvent du markdown) permet de décrire les entrées et sorties de l’API telle qu’on l’envisage avant de l’implémenter. Ici, cette spécification se fait de façon descriptive mais formalisée. Le « concepteur » peut (et doit) laisser tout commentaire utile à la compréhension de cette API.

Le >premier bénéfice d’un tel outil est donc de générer et de mettre en ligne une documentation de l’API. Le second bénéfice est qu’il permet un travail collaboratif sur l’API. Et sa simplicité syntaxique peut le mettre à portée d’un non-technicien. Une façon très pertinente d’aligner « technique » et « métier ».

De tels outils de documentation (Swagger, Redocly, Apiary, Postman, etc.) permettent également de mettre très rapidement en ligne un mock de l’API documentée, avant même son implémentation. Ce principe de mock (comme c’est le cas dans les tests unitaires par exemple) est de simuler le fonctionnement de l’API alors même qu’elle ne soit développée). Ici, on est parfaitement dans le domaine du testing : on propose aux développeurs un outil qui lui donne accès à des possibilités de vérifier des assertions, ou autrement dit, une conformité.

Deux catégories de développeurs sont intéressées par ces outils. Les développeurs qui implémentent l’API vont disposer d’une documentation-spécification et des mocks correspondant pour automatiser des tests. Il s’agit de déterminer si le code réalisé répond bien à la spécification. Ici on est dans une pratique similaire aux tests d’acceptation. La nature technique spécifique des API impose d’autre outils tels que Dredd, ReadyAPI, ou Postman, etc. mais les concepts sont les mêmes. Et les résultats sont les mêmes également en termes de productivité du projet et de qualité des livrables.

Grâce aux outils de documentation interactive d’API, les développeurs qui implémentent les applications consommatrices d’API sont aussi servis. Ils disposent eux aussi d’une spécification qui est testable de manière automatique dans leur code. Elle peut même servir à générer de manière automatique toute la « mécanique » de consommation « bas niveau » de l’API. Et souvent, quand l’API réelle n’est pas tout à fait prête, la documentation interactive permet de commencer à développeur un client sans plus de retard. Ces outils savent aussi versionner les API et permettre ainsi de mieux suivre la compatibilité à travers un cycle de vie long d’une API.

En conclusion, l’intégration des API dans les projets Web est souvent une difficulté majeure. En effet, « raccorder les deux morceaux du pont » n’est pas toujours une chose facile et entraine souvent des déceptions, des retards dans les projets et une tension néfaste entre des équipes « productrices » et « consommatrices » d’API.

La pratique du test d’API, qui s’appuie en grande partie sur une méthodologie de documentation avancée, est une fois encore la réponse à des problématiques de fiabilité, de performance, de maintenabilité, et même de sécurité. Dans une pratique d’ingénierie logicielle rationnelle et efficace, les tests des API sont incontournables dans le socle de testing global d’une méthodologie guidée par les tests. Ce qui est écrit dans notre article sur « le Behavior Driven Developpement » s'applique parfaitement au cas des API.

(1) Pour rappel Application Programing Interface, qui définit donc à la fois un protocole technique et un « service » applicatif délivré à travers ce protocole.

Crédit photo : putilich