web-dev-qa-db-fra.com

Comment tester une API GraphQl?

J'ai besoin d'écrire une suite de tests fonctionnelle (qui testera une API GraphQl). La suite de tests se trouvera dans un référentiel et un conteneur distincts de l'API. 

Une approche à laquelle je pensais serait d’utiliser un framework BDD dans la suite de tests. La suite exécuterait tous les tests BDD après avoir reçu une requête HTTP. 

J'envisageais d'utiliser Cucumber.js comme framework BDD. Je sais qu'il y a npm test. Je ne sais pas comment je vais exécuter les tests. Il est un peu gênant d'utiliser un framework de tests unitaires de cette manière. Cette approche a-t-elle un sens? 

Quel outil existe pour faire quelque chose comme ça? Je suis ouvert à considérer divers langages et outils. 

testingfunctional-testinggraphql
15
Nelson

Karate est une structure relativement nouvelle d'automatisation de tests de services Web qui convient parfaitement pour tester les réponses GraphQL en raison de deux fonctionnalités spécifiques.

  • manipulation de texte: il est facile de lancer des requêtes GraphQL en ligne, de les lire à partir de fichiers (réutilisables) et de remplaçants substitute
  • Assertions JsonPath: bien que les réponses GraphQL soient JSON, elles changent dynamiquement en fonction de la demande (pas de schéma fixe) et ont tendance à être profondément imbriquées. Les assertions JsonPath natives de Karaté vous permettent de vous concentrer uniquement sur les morceaux dont vous avez besoin, et vous pouvez exprimer les résultats attendus sous forme JSON raccourcie, ce qui est très lisible.

Voici un bon exemple: graphql.feature avec un extrait ci-dessous:

# you can also read this query from a file
Given text query =
"""
{
  pokemon(name: "Pikachu") {
    id
    number
    name
    attacks {
      special {
        name
        type
        damage
      }
    }
  }
}
"""
And request { query: '#(query)' }
When method post
Then status 200

# json-path makes it easy to focus only on the parts you are interested in
# which is especially useful for graph-ql as responses tend to be heavily nested
* match $.data.pokemon.number == '025'

# the '..' wildcard is useful for traversing deeply nested parts of the json
* def attacks = get[0] response..special
* match attacks contains { name: 'Thunderbolt', type: 'Electric', damage: 55 }

Même si Karaté nécessite un environnement d'exécution Java, la syntaxe est Cucumber/Gherkin , qui ne dépend pas de la langue. Vous pouvez facilement ajouter des tests de Karaté et reports à votre configuration d'intégration continue existante. Les programmeurs JavaScript se sentiront tout particulièrement chez eux à cause de la manière dont Karaté intègre un runtime JavaScript et prend en charge le langage JSON «indulgent» (aucun guillemet double nécessaire, pas besoin de placer les clés JSON entre guillemets).

Disclaimer: dev ici.

4
Peter Thomas

Vous pouvez simplement utiliser npm test avec le programme d’analyse de votre choix. J'utilise moka et chai. Jest pourrait être un peu mieux puisque je crois que c'est probablement la suite de tests la plus avancée. Vous avez simplement créé des tests comme vous le feriez pour tous les systèmes d'extrémité.

      it('should be null when user is not logged in', async () => {
        const query = `
          query {
            user(id: "") {
              username
              email
            }
          }
        `

    const rootValue = {};
    const context = {};

    const result = await graphql(schema, query, rootValue, context);
    const { data } = result;

    expect(data.user).to.equal(null);
  });

assez simple pour le tester. Vous exécutez également une instruction before insérant l'utilisateur concerné dans votre base de données. Le problème de garder une suite de tests séparée est que vous devrez accéder directement à la base de données. Vos tests ne doivent pas dépendre d'autres appels d'API car cela crée des dépendances inutiles. Donc, si un test est rompu, il est alors plus difficile de comprendre la cause fondamentale.

1
Byrd