Nous vous présentions dans un premier article la mise en place des tests d’API, il faut savoir qu’il existe plusieurs bonnes pratiques à respecter pour bien tester ces API. C’est ce que nous allons voir en détail dans ce second article.
Niveaux de tests
Une API doit être testée et validée à plusieurs niveaux : les tests les plus importants à mettre en place sont :
- Les tests unitaires.
- Les tests d’acceptation et de non-régression.
- Et les tests de sécurité, de performance et de charge.
Ces tests unitaires sont les premiers en lice pour valider le bon fonctionnement d’une API, d’une part techniquement et d’autre part fonctionnellement. Les développeurs sont les principaux acteurs de ces tests, dans la rédaction mais aussi la bonne exécution.
Il est important de valider toutes les méthodes de façon unitaire. Au travers des jeux de données fournis par le métier ou par les testeurs, le développeur devra vérifier les résultats des cas passants et non passants, d’une part techniquement (contrôler que le code retour est le bon), et d’autre part fonctionnellement (les attributs sont correctement valorisés dans le JSON de sortie de l’API).
Ensuite, les tests d’acceptation et de non-régression permettent également de vérifier, sur un environnement de recette par exemple, le bon fonctionnement des API.
Les tests d’acceptation, exécutés par un QA, doivent vérifier que les API sont conformes aux spécifications : scénarios métiers, règle de gestion, caractère obligatoire d’un champ…
Les tests de non-régression (ou TNR) peuvent être les mêmes tests déjà effectués précédemment en développement ou en recette, de manière automatisée si possible, et réalisés lors des montées de version des API (ou en production au quotidien). La capitalisation des tests précédemment joués est très importante dans un projet et permet de sécuriser les futures livraisons, ainsi il est nécessaire d’ajouter de nouveaux tests ou de corriger d’anciens tests si ceux-ci ne correspondent plus au besoin. Par conséquent, l’automatisation des tests API permettra à tout projet d’améliorer son « Time-To-Market » puisque la phase de rejeu des TNR sera nettement plus rapide que si ce rejeu des TNR devait être manuel.
Enfin, les tests de performance et de charge ont pour objectif principal de mesurer les temps de réponse d’une ressource d’API en fonction de sa sollicitation. Pour que le fonctionnement du cache soit bien testé, les jeux de données doivent être en nombre suffisant et représentatifs. Une équipe dédiée effectue généralement ces tests. Des tests de sécurité sont également nécessaires afin de connaitre les faiblesses de vos API et leurs vulnérabilités éventuelles.
Types de tests
Une API se compose de plusieurs méthodes (GET, PUT, POST…) qui peuvent être testées individuellement ou par la mise en place de scénarios de tests. Ces scénarios de tests sont construits via l’enchainement de plusieurs appels API. Une API pourrait ainsi se tester de différentes manières :
- Tests de syntaxes : format, orthographe, caractère obligatoire ou non d’un champ…
- Tests fonctionnels : règle de gestion, calcul…
- Construction et exécution de scénarios de tests, cas de tests métiers.
Les tests de syntaxes sont effectués pour vérifier si une méthode accepte une entrée correcte ou retourne une erreur dans le cas d’une valeur incorrecte.
Voici quelques exemples de tests de syntaxes qui pourraient être mis en place sur vos projets et qui seraient utiles pour vérifier si :
- Le format d’un champ est correct dans la sortie de l’API (Booléen, string, integer, array…).
- Selon la conception définie dans un Swagger par exemple, l’orthographe d’un champ est correcte.
- Laisser les champs obligatoires vides entraîne une erreur ?
- Contrôler que le code erreur est le bon.
- Les champs facultatifs sont acceptés comme prévu.
- Le remplissage de champs avec des types de données incorrects (par exemple, mettre une valeur de texte dans un champ entier) entraîne une erreur.
- …
Afin de vérifier si la méthode exécute correctement l’action prévue, des tests fonctionnels doivent être construits.
On peut citer quelques tests à mettre en place sur un projet d’API selon le contexte :
- Le calcul A est-il effectué correctement avec les paramètres B et C ?
- Le champ X est-il correctement présent si le champ booléen « is_visible » en paramètre est à true ? S’il est à false, le champ est-il bien absent ?
- Selon les dates de début/fin renseignées en paramètre, les opérations bancaires d’un client sont-elles correctes ?
- La fonctionnalité de tri (croissant ou décroissant) fonctionne-t-elle correctement selon les paramètres en entrée ?
- L’API retourne-t-elle correctement les 50 dernières opérations bancaires selon le paramètre de rang renseigné en entrée ?
- …
Pour des tests d’API, il faut également mettre en place des scénarios complets de tests. Ces scénarios doivent correspondre à des cas métiers.
Ces mêmes tests trouvent leurs équivalents dans les tests front où le testeur pourra d’abord effectuer des tests sur des composants individuels (test d’un bouton ou d’un champ) puis effectuera des tests complets (création d’une commande jusqu’au paiement par exemple).
L’ensemble des tests réalisés doivent être intégré dans un processus d’intégration continue : cette démarche d’industrialisation est nécessaire afin de diminuer le risque de régression et vérifier rapidement la validité d’une modification du code. Ces modifications de code doivent être maitrisées et repérées le plus tôt possible. Le principe de test (défini par l’ISTQB) du « Tester tôt » trouve tout son sens ici : il est plus simple, plus rapide et plus économique de corriger une anomalie dans la phase de développement ou de recette que lors de la mise en production.
L’intégration continue aide votre équipe à livrer plus rapidement et plus fréquemment des mises à jour auprès des clients.
Afin de diminuer le risque d’incident majeur en production, il est nécessaire d’enrichir cette batterie de tests de non-régression avec des nouveaux tests correspondant à d’autres scénarios métiers.
Bien sûr, ces tests doivent être joués régulièrement et de manière automatisée. Des rapports de réussite ou d’échec des tests vous alerteront en temps réel quant à la qualité des développements.
Mesure de la qualité des API
Afin de mesurer la qualité d’une API, il peut être nécessaire de mettre en place des métriques. Celles-ci peuvent vous fournir un excellent moyen de vérifier des indicateurs clés. Ces métriques sont évidemment surtout destinées à un profil technique plutôt qu’à un QA qui sera focalisé sur l’aspect fonctionnel de l’API.
Voici quelques exemples de métriques utiles à tout projet d’API :
- Disponibilité 24/7/365.
- Consommation / trafic.
- Taux d’erreur.
La disponibilité d’une API est peut-être l’indicateur le plus suivi dans un projet d’API. Une API qui n’est pas disponible à un instant T peut provoquer une interruption de service pour l’application ou le site consommateur de ces API.
Une API doit approcher une disponibilité proche de 100% !
La consommation d’une API est un bon indicateur à mettre en place dans vos tableaux de bord. Plus une API est consommée, plus il faut mettre les moyens humains et financiers pour faire évoluer l’API ou en créer de nouvelles dont les données sont complémentaires.
Enfin, la scalabilité d’une API est la capacité d’une API à maintenir ses performances et ses fonctionnalités en cas de forte sollicitation.
Quelques indicateurs clés de mesure :
- Temps de réponse
- Consommation CPU
- Nombre de requêtes par seconde
Ces KPI sont un bon moyen de focaliser l’effort de l’équipe de développement vers une démarche d’amélioration continue des API.
Conclusion
Les tests d’API nécessitent une véritable stratégie de test et doivent être le fruit d’une réflexion avec tous les acteurs d’un projet (développeur, testeur, chef de projet…). Les types de tests ne sont pas les mêmes selon l’environnement de test et selon celui qui conçoit et exécute les tests. “Tester, c’est douter” ? Non, les tests d’API sont indispensables, n’hésitez pas à investir massivement dans ces phases de tests, vous n’en serez que plus serein lors de vos mises en production !
