Test automatisé pour REST Api
J'aimerais rédiger une suite de tests automatisés pour une API REST. Au fur et à mesure que nous complétons de nouveaux services, nous souhaitons nous assurer que tous les services créés précédemment fonctionnent comme prévu. Des suggestions sur les meilleurs outils à utiliser pour y parvenir? Je connais des outils comme Apigee qui permettent de tester un service à la fois, mais nous aimerions pouvoir tester tous les services en un clic.
Au cours de mon travail, nous avons récemment mis au point deux suites de tests écrites en Java pour tester certaines API RESTful que nous avons créées. Nos services peuvent appeler d'autres API RESTful dont ils dépendent. Nous l'avons divisé en deux suites.
- Suite 1 - Test de chaque service de manière isolée
- Simulez tous les services homologues pour lesquels l’API dépend de l’utilisation de restito . Les autres alternatives incluent rest-driver , wiremock et betamax .
- Teste le service que nous testons et les simulacres s'exécutent dans une seule JVM.
- Lance le service dans la jetée
Je recommanderais certainement de le faire. Cela a très bien fonctionné pour nous. Les principaux avantages sont:
- Les services homologues sont simulés, vous n'avez donc pas besoin de configurer des données compliquées. Avant chaque test, vous utilisez simplement restito pour définir le comportement des services homologues, comme vous le feriez avec des classes dans les tests unitaires avec Mockito.
- Vous pouvez demander aux services homologues simulés s’ils ont été appelés. Vous ne pouvez pas faire ces assertions aussi facilement avec de vrais services homologues.
- La suite est très rapide car les services simulés servent des réponses pré-conservées en mémoire. Ainsi, nous pouvons obtenir une bonne couverture sans que la suite ne prenne l'âge de courir.
- La suite est fiable et reproductible car isolée dans sa propre JVM, vous n'avez donc pas à vous soucier des autres suites/personnes qui travaillent dans un environnement partagé en même temps que la suite est en cours d'exécution et que les tests échouent.
- Suite 2 - Complet de bout en bout
- Suite fonctionne sur un environnement complet déployé sur plusieurs machines
- API déployée sur Tomcat en environnement
- Les services entre pairs sont de véritables déploiements complets «en direct»
Cette suite nous oblige à configurer les données dans des services homologues, ce qui signifie que les tests prennent généralement plus de temps à écrire. Nous utilisons autant que possible les clients REST pour configurer les données dans des services homologues.
Les tests dans cette suite prennent généralement plus de temps à écrire, nous avons donc mis l'essentiel de notre couverture dans la Suite 1. Cela étant dit, cette suite a toujours une valeur évidente dans la mesure où nos simulacres de la Suite 1 peuvent ne pas se comporter exactement comme les services réels.
Frisby est un framework de test d'API REST basé sur node.js et Jasmine qui permet de tester les points de terminaison d'API de manière simple, rapide et amusant. http://frisbyjs.com
Exemple:
var frisby = require('../lib/frisby');
var URL = 'http://localhost:3000/';
var URL_AUTH = 'http://username:password@localhost:3000/';
frisby.globalSetup({ // globalSetup is for ALL requests
request: {
headers: { 'X-Auth-Token': 'fa8426a0-8eaf-4d22-8e13-7c1b16a9370c' }
}
});
frisby.create('GET user johndoe')
.get(URL + '/users/3.json')
.expectStatus(200)
.expectJSONTypes({
id: Number,
username: String,
is_admin: Boolean
})
.expectJSON({
id: 3,
username: 'johndoe',
is_admin: false
})
// 'afterJSON' automatically parses response body as JSON and passes it as an argument
.afterJSON(function(user) {
// You can use any normal jasmine-style assertions here
expect(1+1).toEqual(2);
// Use data from previous result in next test
frisby.create('Update user')
.put(URL_AUTH + '/users/' + user.id + '.json', {tags: ['jasmine', 'bdd']})
.expectStatus(200)
.toss();
})
.toss();
J'ai collaboré avec l'un de mes collègues pour lancer le framework PyRestTest pour cette raison: https://github.com/svanoort/pyresttest
Bien que vous puissiez travailler avec les tests en Python, le format de test normal est en YAML.
Exemple de suite de tests pour une application REST de base - vérifie que les API répondent correctement en vérifiant les codes d'état HTTP, bien que vous puissiez lui demander également d'examiner le corps des réponses:
---
- config:
- testset: "Tests using test app"
- test: # create entity
- name: "Basic get"
- url: "/api/person/"
- test: # create entity
- name: "Get single person"
- url: "/api/person/1/"
- test: # create entity
- name: "Get single person"
- url: "/api/person/1/"
- method: 'DELETE'
- test: # create entity by PUT
- name: "Create/update person"
- url: "/api/person/1/"
- method: "PUT"
- body: '{"first_name": "Gaius","id": 1,"last_name": "Baltar","login": "gbaltar"}'
- headers: {'Content-Type': 'application/json'}
- test: # create entity by POST
- name: "Create person"
- url: "/api/person/"
- method: "POST"
- body: '{"first_name": "Willim","last_name": "Adama","login": "theadmiral"}'
- headers: {Content-Type: application/json}
J'ai utilisé SOAP UI pour les tests fonctionnels et automatisés. SOAP L'interface utilisateur vous permet d'exécuter les tests en un clic. Il existe également un contrôleur de ressorts test page créé par Ted Young. J'ai utilisé cet article pour créer des tests unitaires Rest dans notre application.
L'un des problèmes liés aux tests automatisés pour les API est que nombre de ces outils nécessitent que le serveur d'API soit opérationnel avant de lancer votre suite de tests. Avoir une infrastructure de test unitaire capable d'exécuter et d'interroger les API dans un environnement de test entièrement automatisé peut constituer un réel avantage.
Une option intéressante pour les API implémentées avec Node.JS/Express consiste à utiliser mocha pour les tests automatisés. En plus des tests unitaires, il est facile d’écrire des tests fonctionnels par rapport aux API, séparés en différentes suites de tests. Vous pouvez démarrer le serveur API automatiquement dans l'environnement de test local et configurer une base de données de test locale. En utilisant make, npm et un serveur de construction, vous pouvez créer une cible "make test" et une construction incrémentielle qui exécutera la suite de tests complète chaque fois qu'un élément de code est soumis à votre référentiel. Pour le développeur vraiment fastidieux, il générera même un rapport de couverture de code HTML Nice indiquant les parties de votre base de code couvertes ou non par les tests. Si cela semble intéressant, voici un blog post qui fournit tous les détails techniques.
Si vous n'utilisez pas de noeud, quel que soit le framework de test d'unité de facto pour le langage (jUnit, concombre/capybara, etc.), voyez son support pour la rotation de serveurs dans l'environnement de test local et l'exécution des requêtes HTTP. S'il s'agit d'un projet volumineux, les efforts pour obtenir des tests d'API automatisés et une intégration continue fonctionneront assez rapidement.
J'espère que cela pourra aider.
Runscope est un service basé sur un nuage qui peut surveiller les API Web à l'aide d'un ensemble de tests. Les tests peuvent être, programmés et/ou exécutés via des hooks Web paramétrés. Des tests peuvent également être exécutés à partir de centres de données du monde entier pour garantir que les temps de réponse sont acceptables pour la clientèle mondiale.
Le niveau gratuit de Runscope prend en charge jusqu’à 10 000 requêtes par mois.
Avertissement: je suis un avocat développeur pour Runscope.
Vous pouvez également utiliser la bibliothèque Rest Assured. Pour une démonstration avec un exemple de script, consultez http://artoftesting.com/automationTesting/restAPIAutomationGetRequest.html
J'ai implémenté de nombreux cas d'automatisation basés sur REST Assured, un DSL jave permettant de tester un service reposant. https://code.google.com/p/rest-assured/
La syntaxe est simple, il supporte json et xml. https://code.google.com/p/rest-assured/wiki/Usage
Avant cela, j'ai essayé SOAPUI et quelques problèmes avec la version gratuite. De plus, les cas sont dans des fichiers XML difficiles à étendre et à réutiliser, simplement, je n'aime pas
L'automatisation des tests d'API, jusqu'à une fois par minute, est un service disponible via theRightAPI . Vous créez vos scénarios de test et les exécutez. Une fois que ces tests répondent à vos attentes, vous pouvez les planifier. Les tests peuvent être «chaînés» pour des scénarios nécessitant une authentification. Par exemple, vous pouvez avoir un test qui envoie une demande OAuth à Twitter et crée un jeton partagé qui peut ensuite être utilisé par tout autre test. Les tests peuvent également avoir des critères de validation attachés pour garantir les codes de statut http, voire une inspection détaillée des réponses à l'aide de javascript ou de la validation de schéma. Une fois les tests programmés, vous pouvez faire en sorte que les alertes vous avertissent dès qu'un test en particulier échoue à la validation ou se comporte en dehors des plages établies pour le temps de réponse ou la taille de la réponse.
J'ai utilisé les classes HTTP TestNG et Apache pour créer mon propre framework de test d'API REST, J'ai développé ce concept après deux ans d'utilisation de Selenium.
Tout est pareil, sauf que vous devez utiliser les classes HTTP Apache au lieu des classes Selenium.
essayez, c’est vraiment mignon et bon, vous avez le pouvoir de personnaliser votre cadre de test au maximum de vos possibilités.