Depuis plusieurs mois une question m’est posée de plus en plus fréquemment: comment tester une API ?
Il est vrai que la taverne n’avait pas, à ce jour, d’articles spécifiques à ce sujet. Attention l’objet de cet article n’est pas de parler d’outil pour ces tests, il y en a déjà sur des outils comme Postman sur ce blog, mais bien d’essayer de vous présenter une manière d’appréhender ces tests.
Les points communs entre tests API et tests IHM
Lorsqu’un testeur parle de test d’un logiciel il parle généralement de tests système. Pour rappel ces tests sont les tests visant à valider un comportement par rapport à des spécifications. Que l’on soit avec un logiciel proposant une interface graphique ou non la première chose à faire est de s’approprier le logiciel, comprendre son fonctionnement et appréhender le contexte dans lequel est ce logiciel.
Il y a plusieurs manière de s’approprier le logiciel, il est évidemment possible de lire de la documentation mais il est également toujours bien, lorsque c’est possible d’échanger avec des sachants et de manipuler le logiciel. Ces échanges et manipulation permettent de comprendre le but du logiciel, commencer à intégrer la manière de l’utiliser et commencer à identifier de potentielles faiblesses.
Lorsque cela est fait il est possible de commencer à se pencher sur comment le logiciel sera testé et sur quelles parties les tests se pencheront le plus… et c’est à partir de là que les divergences entre tests d’APIs et tests d’IHM de logiciels commencent à se faire sentir.
Les différences entre les tests d’APIs et les tests IHM
Les tests d’IHM sont assez « instinctifs » dans le sens où l’on va tester ce que n’importe quel utilisateur sera amené à voir à travers une interface graphique. Les testeurs proposent alors des « parcours » de test souvent semblables à des parcours utilisateurs. On passe alors souvent à travers une série d’écrans pour arriver à un écran final censé nous donner les informations recherchées par le test.
Dans le cas des tests APIs c’est légèrement différents! Ici on ne voit pas défiler les écrans. On travaille avec des « messages » formatés contenant diverses informations et auxquels on doit répondre avec un autre message également formaté. Les réponses dépendant du contenu des messages reçus. Il est évidemment possible de proposer des « parcours » comme sur des IHM avec un ensemble de messages échangés mais ces parcours traversent régulièrement plusieurs APIs et au final c’est rarement l’objectifs de ces tests souvent plus bas niveau que les tests IHM.
Comme vous l’avez compris les tests d’APIs se concentrent généralement sur les messages. Chaque API pouvant généralement gérer plusieurs types de message il peut être préférable de traiter, au moins dans un premier temps, ces messages de manières distinctes et de les tester en profondeur… Un intérêt des tests d’API est qu’ils sont rapides à automatiser et à implémenter avec les outils adéquates.
Par rapport au messages des API, ce sont des messages formatés dans lesquels se trouvent des informations qui peuvent prendre la forme de variables ou de paramètres. Par exemple, dans une API de connexion un message formaté sera envoyé (dans un message sécurisé) avec les informations de login et de mot de passe (crypté!) plus d’autres informations si nécessaires. Les tests d’API devront donc tester le cet API en proposant des messages où les contenus des variables login et mots de passe sont variés. On peut penser à des cas de massage comme :
- couple login/mdp OK
- couple login/mdp KO mais avec un login et un mdp existant
- pas de mdp
- pas de login
- pas de login ni mdp
- formats incorrects de variables
- formats incorrects de messages…
Au final on peut très vite multiplier les cas en jouant sur les données… et c’est justement là l’intérêt des tests APIs: multiplier facilement les tests.
Au final, pour les habitués des tests IHM, vous pouvez voir les tests d’APIs comme des tests de formulaires! L’architecture du message étant le formulaire et les données du message les différents champs du formulaire (l’exemple du login/mdp est d’ailleurs un formulaire au format très simple).
Conclusion
Les tests d’API ne sont pas si différents des tests d’IHM sur le point de vue du travail initial du testeur. Les différences sont par contre très importantes d’un point de vue opérationnel. En effet les tests d’APIs sont des tests de messages et ils sont déstabilisants pour des testeurs habitués à des interfaces. Dès que ce cap est passé on s’aperçoit que ces tests, plus techniques, sont des tests qui ne se concentrent pas forcément sur un parcours utilisateurs comme beaucoup de tests IHM mais plutôt sur une partie de ce parcours. L’absence d’IHM et le formatage des messages permet alors facilement de multiplier les données de tests et donc de tester plus en profondeur la réponse de l’API aux différents messages…
Ces tests sont des tests avec des outils spécifiques et souvent intéressants à automatiser de par leur « répétitivité » induite par la vérification d’un même message dont les seules différences (dans le cas de tests où l’on ne vérifie pas un mauvais formatage du message) sont les variables à tester.
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
