Tests automatisés pour l'Api REST

Question

J'aimerais écrire une suite de tests automatisés pour une API REST. Au fur et à mesure que nous créons de nouveaux services, nous aimerions nous assurer que tous les services précédemment créés fonctionnent comme prévu. Avez-vous des suggestions sur les meilleurs outils à utiliser pour y parvenir ? Je sais qu'il existe des outils comme Apigee qui permettent de tester un service à la fois, mais nous aimerions pouvoir tester tous les services en cliquant sur un bouton.

Answer 1

À mon travail, nous avons récemment mis au point deux suites de tests écrites en Java pour tester certaines API RESTful que nous avons construites. Nos services peuvent invoquer d'autres API RESTful dont ils dépendent. Nous les avons divisées en deux suites.

---

• Suite 1 - Tester chaque service de manière isolée
  • Mocker tous les services homologues dont dépend l'API à l'aide de restito . Parmi les autres alternatives, on peut citer conducteur de repos , maille métallique et betamax .
  • Teste le service que nous testons et les mocks s'exécutent tous dans une seule JVM
  • Lance le service dans Jetty

Je vous recommande vivement de le faire. Cela a très bien fonctionné pour nous. Les principaux avantages sont les suivants :

• Les services pairs sont simulés, de sorte qu'il n'est pas nécessaire de procéder à une configuration compliquée des données. Avant chaque test, vous utilisez simplement restito pour définir comment vous voulez que les services pairs se comportent, tout comme vous le feriez avec des classes dans des tests unitaires avec Mockito.
• Vous pouvez demander aux services homologues simulés s'ils ont été appelés. Vous ne pouvez pas faire ces affirmations aussi facilement avec de vrais services homologues.
• La suite est très rapide car les services simulés servent des réponses en mémoire préétablies. Nous pouvons donc obtenir une bonne couverture sans que la suite ne prenne une éternité à s'exécuter.
• La suite est fiable et reproductible car elle est isolée dans sa propre JVM, il n'est donc pas nécessaire de s'inquiéter que d'autres suites/personnes s'occupent d'un environnement partagé au moment où la suite est en cours d'exécution et que les tests échouent.

---

• Suite 2 - Complète d'un bout à l'autre
  • La suite fonctionne dans un environnement complet déployé sur plusieurs machines.
  • API déployée sur Tomcat dans l'environnement
  • Les services pairs sont des déploiements complets "en direct".

Cette suite nous oblige à configurer les données dans les services homologues, ce qui signifie que les tests prennent généralement plus de temps à écrire. Dans la mesure du possible, nous utilisons des clients REST pour configurer les données dans les services homologues.

Les tests de cette suite sont généralement plus longs à écrire, c'est pourquoi nous plaçons la majeure partie de notre couverture dans la suite 1. Ceci étant dit, il y a toujours une valeur claire dans cette suite car nos simulacres dans la Suite 1 peuvent ne pas se comporter tout à fait comme les vrais services.

---

Answer 2

Frisby est un framework de test d'API REST construit sur node.js et Jasmine qui rend les tests de points d'extrémité d'API faciles, rapides et amusants. 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();

Answer 3

C'est pour cette raison que j'ai collaboré avec l'un de mes collègues pour créer le framework PyRestTest : https://github.com/svanoort/pyresttest

Bien que vous puissiez travailler avec les tests en Python, le format normal des tests est en YAML.

Exemple de suite de tests pour une application REST de base -- vérifie que les API répondent correctement, en contrôlant les codes d'état HTTP, bien que vous puissiez également lui faire examiner les corps de réponse :

---
- 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}

Answer 4

J'ai utilisé SOAP UI pour les tests fonctionnels et automatisés. L'interface SOAP vous permet d'exécuter les tests en cliquant sur un bouton. Il existe également un essais des contrôleurs de ressort page créée par Ted Young. J'ai utilisé cet article pour créer des tests unitaires Rest dans notre application.

Answer 5

L'un des problèmes liés à la réalisation de tests automatisés pour les API est que de nombreux outils exigent que le serveur API soit opérationnel avant d'exécuter la suite de tests. Il peut être très avantageux de disposer d'un cadre de test unitaire capable d'exécuter et d'interroger les API dans un environnement de test entièrement automatisé.

Une option intéressante pour les API implémentées avec Node.JS / Express est d'utiliser mocha pour les tests automatisés. En plus des tests unitaires, il est facile d'écrire des tests fonctionnels contre les 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 mettre en place 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émentale qui exécutera la suite de tests complète chaque fois qu'un morceau de code est soumis à votre référentiel. Pour les développeurs les plus pointilleux, il est même possible de générer un rapport HTML sur la couverture du code, vous indiquant quelles parties de votre base de code sont couvertes par des tests ou non. Si cela vous semble intéressant, voici un article de blog qui fournit tous les détails techniques.

Si vous n'utilisez pas node, quel que soit le framework de test unitaire de facto pour le langage (jUnit, cucumber/capybara, etc.) - regardez s'il prend en charge la création de serveurs dans l'environnement de test local et l'exécution des requêtes HTTP. S'il s'agit d'un projet de grande envergure, les efforts déployés pour automatiser les tests d'API et l'intégration continue seront rapidement récompensés.

J'espère que cela vous aidera.