Les bases du test des API RESTful
Le test d’API RESTful insuffle au sein de l’entreprise une culture de tests en continu et d’une forme de responsabilité de l’équipe. Greg Sypolt passe en revue les composants clés d’un programme de test.
En matière de test d’applications Web, la pratique standard consiste depuis des années à tester les front-ends graphiques côté utilisateurs. Toutefois, cette pratique a subi quelques transformations.
Pour déployer des pipelines de delivery plus modernes, qui reposent sur l’intégration et la livraison continue (CI/CD), les équipes doivent-elles aussi évoluer : celles-ci doivent au moins intégrer des processus d’automatisation, et l’accent, centré initialement sur la prévention de bugs, doit désormais se focaliser sur la qualité, et ce, en avance de phase.
Ainsi, développeurs, chefs de produit, analystes et testeurs ont pour objectif d’anticiper la création d’un catalogue d’outils de tests. Comment ? En favorisant la collaboration : il s’agit d’identifier les critères d’acceptation nécessaires pour satisfaire les besoins, et convenir, ensemble, de la meilleure façon d’effectuer les tests. Cela nécessite aussi des tests de plus bas niveau – comme ceux d’API.
Cette approche a un point de départ : le test des API RESTful. Cet article vous explique pourquoi le test d’API est nécessaire et comment concevoir ces phases très critiques, pour terminer sur les outils nécessaires au processus.
API RESTful : qu’est-ce que c’est ?
En termes profanes, REST est une méthode de communication pour que deux ordinateurs puissent dialoguer via Internet. L’un fait office de navigateur Web et l’autre agit comme un serveur Web. Le transfert s’effectue via le Web et via donc les protocoles HTTP/HTTPS (GET, PUT, POST et DELETE).
Les deux méthodes les plus utilisées sont GET et POST :
- GET est utilisé pour obtenir les données d’une source identifiée ;
- POST est utilisé pour envoyer les données à traiter vers une source spécifique.
Un exemple : l’API GitHub pour repository_url – comme l’illustration le montre ci-dessous.
L’architecture REST multicouche
L’architecture REST est en fait un design pattern implémenté dans une pile organisée en couches. Les couches traditionnelles vous aident à mieux organiser le code. Une application peut ainsi disposer des couches suivantes : celle gérant la présentation, celle la logique métier, une autre l’accès aux données et une autre le stockage de données.
La couche présentation
La couche du dessus est celle gérant l’interface utilisateur. Elle traduit les réponses dans un format compréhensible par la machine afin que les utilisateurs puissent le lire. Cette couche présentation prend en charge la représentation du contenu, comme le montre l’illustration ci-dessous :
La logique métier
Cette couche logique est le cerveau de l’application. Elle traite et communique les données entre les couches et prend les décisions logiques – comme l’authentification et les autorisations, l’auditing et la gestion des exceptions, par exemple.
L’accès aux données
Cette couche propose un accès simplifié aux données stockées – dans une base de données, sous la forme de fichiers plats, par exemple. Elle est séparée de la couche dédiée à la logique métier et à la présentation. Celle-ci est étroitement liée à la couche qui gère le stockage de données.
Le stockage des données
Cette couche est en fait une base de données relationnelle, NoSQL, un système de fichiers, un stockage cloud ou In-Memory.
Créer une méthode pour le développement et le test
Lorsque vous créez votre stratégie de test d’API RESTful, il est important de mettre à plat tout ce qui est nécessaire lors d’un sprint et de la création d’une version. Disposer d’une bonne stratégie de test améliorera la collaboration et la communication dès les premières phases de développement. On constate généralement une hausse de productivité lorsque tout le monde joue le jeu en matière de responsabilité et s’implique dans la qualité.
La pyramide de l’expérience utilisateur
Lorsque vous lancez et maintenez une API, chaque membre de l’équipe doit considérer tous les aspects de l’expérience utilisateur. Cette pyramide représente plusieurs caractéristiques à prendre en compte.
Le choix de la technologie
Il existe une kyrielle d’outils de test : Open Source, fournisseurs, et à façon. Il s’agit avant tout de rester pragmatique et d’évaluer les besoins.
Couverture des tests
Le développement de produits de qualité requiert une stratégie de test adaptée. Cela démarre dès l’écriture de code en intégrant, en parallèle, du code de test lors des phases du sprint. Les tests unitaires représentent l’épine dorsale de toutes stratégies de test.
Définir les standards
Il est important de fixer les standards en avance et de les communiquer à tous les membres de l’équipe. Cela évitera par exemple les sueurs froides lors de changements inattendus. Il faut évaluer et recalibrer en permanence si nécessaire.
Responsabilités
Il faut définir très clairement les responsabilités de chaque membre, que ce soit au niveau des développeurs, des testeurs, des DevOps et des chefs de produit.
Tests en continu
Le test en continu : il ne s’agit pas uniquement de l’implémentation de tests d’API. Il s’agit avant tout d’une stratégie, d’une sélection d’outils, puis d’une implémentation de tests. Une fois cela en place – et si soutenu par une bonne analyse –, le test en continu améliore la qualité des applications et de l’ensemble de la chaîne de livraison.
Test d’API RESTful : quelles sont les technologies
La principale difficulté est d’identifier la bonne technologie pour son projet. Il existe plusieurs raisons pour cela :
- Méconnaissance de tous les outils du marché ou des frameworks de tests ;
- Manque d’expertise ou de connaissances pour déployer ou adapter un framework en place ;
- Impossibilité de s’offrir les coûteux outils des fournisseurs ;
- Manque de temps ou de ressources pour développer une batterie de tests personnalisée dans une approche « bottom-up ».
Voici quelques outils ou frameworks les plus utilisés pour automatiser le test d’API :
| Open Source |
Fournisseur |
Custom |
Conclusion
Une stratégie de test n’est pas qu’un simple document qui pose les choses. Elle est le fruit de réflexions qui prennent en compte toutes les activités – développement, test, ainsi que la spirale de la méthode en continu. Cela améliore l’ensemble de la chaîne de livraison en accélérant les feedbacks et en intégrant une approche agile avec ses courtes itérations.
