A propos de l'auteur

Kelvin Omereshone est le CTO de Quru Lab. Kelvin était auparavant ingénieur front-end chez myPadi.ng. Il est le créateur de la communauté Nuxtjs Africa et très passionné…
Plus à propos
Kelvin

Cet article présente Mirage JS, une bibliothèque de simulation d'API qui vous permet de créer, de tester et de partager une application JavaScript fonctionnelle complète sans avoir recours à une API ou à des services principaux. Vous apprendrez également comment configurer Mirage JS avec le framework frontal progressif, Vue.js.

À l'ère du SPA et du JAMstack, il y a toujours eu une séparation des préoccupations entre les API et le développement frontal. Presque tous les projets JavaScript qui peuvent être trouvés dans la nature interagissent avec un service Web ou une API et l'utilisent pour des authentifications ou pour obtenir des données liées à l'utilisateur.

Ainsi, chaque fois que vous travaillez sur un projet et que l'API nécessaire n'a toujours pas été implémentée par l'équipe principale ou que vous devez tester rapidement une fonctionnalité, vous disposez de certaines des options suivantes:

  • Vous pouvez créer un proxy vers une version exécutée localement de votre backend réel que, dans la plupart des cas, en tant que développeur frontal, vous n'auriez pas.
  • Vous pouvez commenter la demande réelle et la remplacer par des données factices. (C'est correct, mais pas aussi grand que vous auriez besoin de l'annuler pour accéder à la production et vous pourriez ne pas être en mesure de gérer les états du réseau et la latence.)

Qu'est-ce que l'API Mocking?

La simulation d'API est une imitation ou une simulation d'une API réelle. Cela est principalement fait afin d'intercepter les demandes qui sont censées être adressées à une API backend réelle, mais cette simulation existe sur votre frontend.

Pourquoi le mocking API est-il important

Le mocking API est très important à bien des égards:

  1. Cela permet une très bonne expérience de développement front-end de ne pas dépendre des API de production avant de créer des fonctionnalités.
  2. Vous pouvez partager l'intégralité de votre frontend et cela fonctionnerait sans dépendre d'une API backend réelle.

Qu'est-ce que Mirage JS?

Mirage JS a été créé il y a 5 ans et était à peu près utilisé dans la communauté Ember avant Sam Selikoff officiellement annoncé sa sortie le 24 janvier 2020 sur Twitter.

Mirage JS résout le problème de tester les API backend sans dépendre de ces API. Il permet une expérience de développement front-end transparente en se moquant des API de production.

Mirage JS est une bibliothèque de simulation d'API pour les frameworks Vue.js, React, Angular et Ember

Qu'est-ce qui fait de Mirage JS un meilleur choix?

Il y a eu d'autres options pour le mocking d'API (comme les intercepteurs Axios, le serveur JSON de Typicode, etc.) mais ce que je pense est assez intéressant à propos de Mirage, c'est qu'il ne gêne pas votre processus de développement (comme vous le verriez quand nous l'avons installé avec Vue dans un peu). Il est léger et pourtant puissant.

Il est livré avec une batterie incluse prête à l'emploi qui vous permet de reproduire des scénarios de consommation d'API de production réels, comme la simulation d'un réseau lent avec son option de synchronisation.

Mise en route avec Mirage JS et Vue.js

Alors maintenant que vous savez ce qu'est Mirage JS et pourquoi il est important pour votre flux de travail de développement frontal, examinons la configuration avec le framework Web progressif: Vue.js.

Création d'un projet de vue Green-Field (Clean Installation)

À l'aide de l'interface CLI, créez une nouvelle Vue.js projet en allant dans le répertoire dans lequel vous souhaitez créer et exécuter le projet (dans votre terminal):

vue créer miragejs-demo-vue 

La commande ci-dessus mettrait en place un nouveau projet Vue que vous pouvez maintenant CD dans et exécuter soit fil servir ou npm run serve.

#Installation de Mirage JS

Installons maintenant Mirage JS en tant que dépendance de développement dans notre Vue.js projet en exécutant la commande suivante:

ajout de fil -D miragejs

Ou si vous utilisez NPM, exécutez ceci:

npm install --save-dev miragejs

Et c'est tout! Mirage JS est maintenant installé dans notre Vue.js projet.

Mock Out quelque chose

Une fois Mirage JS installé, voyons comment nous le configurons pour parler à Vue et simuler une API de base todos (une API qui renvoie une liste de todos).

Définissez votre serveur

Pour commencer, nous devons créer un server.js fichier dans le / src répertoire de nos Vue.js projet. Après cela, ajoutez ce qui suit:

importer {Server, Model} depuis 'miragejs'

fonction d'exportation makeServer ({environnement = "développement"} = {}) {

laisser serveur = nouveau serveur ({
  environnement,

    des modèles: {
      todo: modèle,
    },

  graines (serveur) {
  server.create ("todo", {content: "Learn Mirage JS"})
  server.create ("todo", {content: "Integrate With Vue.js"})
  },

  routes () {

    this.namespace = "api"

    this.get ("/ todos", schéma => {
      renvoie schema.todos.all ()
    })
    
  },
  })

  serveur de retour
}

Code expliqué

Premièrement, le server.js fichier est la façon dont vous configurez Mirage JS pour créer une nouvelle instance de son faux serveur (faux) qui interceptera tous les appels d'API que vous effectuez dans votre application correspondant aux itinéraires que vous définissez.

Maintenant, je conviens que ce qui précède peut être écrasant au début, mais examinons de plus près ce qui se passe ici:

importer {Server, Model} depuis 'miragejs'

À partir de l'extrait de code ci-dessus, nous importons Serveur et Modèle de miragejs.

  • Serveur
    Ceci est une classe exposée par Mirage pour nous aider à instancier une nouvelle instance d'un serveur Mirage JS pour «servir» comme notre faux serveur.
  • Modèle
    Une autre classe exposée par Mirage pour aider à créer des modèles (un modèle détermine la structure d'une entrée de base de données Mirage JS) alimentée par l'ORM de Mirage.
fonction d'exportation makeServer ({environnement = "développement"} = {}) {}

Ce qui précède exporte essentiellement une fonction appelée makeServer du src / server.js. Vous pouvez également noter que nous transmettons un paramètre d'environnement et que nous définissons le mode d'environnement de Mirage sur développement (vous nous verriez passer l'environnement de test plus loin dans cet article).

Le corps de makeServer

Maintenant, nous faisons deux ou trois choses dans le makeServer corps. Nous allons jeter un coup d'oeil:

laisser serveur = nouveau serveur ({})

Nous instancions une nouvelle instance de la classe Server et lui transmettons une option de configuration. Le contenu des options de configuration permet de configurer mirage:

{
  environnement,

  des modèles: {
    todo: modèle,
  },

  graines (serveur) {
  server.create ("todo", {content: "Learn Mirage JS"})
  server.create ("todo", {content: "Integrate With Vue.js"})
  },

  routes () {

    this.namespace = "api"

    this.get ("/ todos", schéma => {
      renvoie schema.todos.all ()
    })
  },
  
  }

Nous passons d'abord le environnement paramètre que nous avons initialisé dans la définition de la fonction.

des modèles: {
    todo: modèle,
  },

L'option suivante qui est la des modèles L'option prend un objet des différents modèles que nous voulons que Mirage moque.

Dans ce qui précède, nous voulons simplement un modèle de tâches que nous instancions à partir de la classe Model.

graines (serveur) {
server.create ("todo", {content: "Learn Mirage JS"})
server.create ("todo", {content: "Integrate With Vue.js"})
},

L'option suivante est la méthode seed qui prend un paramètre appelé serveur. La méthode des graines permet de créer des graines (les graines sont des données initiales ou une entrée dans la base de données de Mirage) pour nos modèles. Dans notre cas, pour créer les graines du modèle de tâches, nous faisons:

server.create ("todo", {content: "Learn Mirage JS"})
server.create ("todo", {content: "Integrate With Vue.js"})

le serveur a donc une méthode create qui attend comme premier argument une chaîne qui correspond au nom du modèle, puis un objet qui contiendra les propriétés ou les attributs d'une graine particulière.

routes () {

    this.namespace = "api"

    this.get ("/ todos", schéma => {
      renvoie schema.todos.all ()
    })
  },

enfin, nous avons la méthode routes qui définit les différentes routes (les routes sont nos noeuds finaux de l'API fictive) Mirage JS va se moquer. Regardons le corps de la méthode:

this.namespace = "api"

cette ligne définit l'espace de noms pour toutes les routes, ce qui signifie que notre route todo est désormais accessible à partir de / api / todos.

this.get ("/ todos", schéma => {
  renvoie schema.todos.all ()
})

Ce qui précède crée un itinéraire d’obtention et son gestionnaire utilise le this.get () méthode. le avoir() attend la route, c'est-à-dire «/ todos» et une fonction de gestionnaire qui prend en schéma comme argument. L'objet de schéma est la façon dont vous interagissez avec l'ORM de Mirage qui est alimenté par la base de données en mémoire Mirage JS.

Finalement:

renvoie schema.todos.all ()

Nous retournons une liste de tous nos todos, en utilisant l'objet de schéma rendu possible par l'ORM de Mirage.

src / main.js

Nous avons donc terminé la mise en place src / server.js mais Vue ne le sait pas (du moins pas encore). Alors importons-le dans notre main.js fichier comme ça:

importer {makeServer} depuis "./server"

Ensuite, nous appelons le makeServer fonctionner comme ça:

if (process.env.NODE_ENV === "développement") {
  makeServer ()
}

Ce qui précède si conditionnel est un gardien pour s'assurer que le mirage ne fonctionne que pendant le développement.

Configuration terminée!

Nous avons maintenant configuré Miragejs avec Vue. Voyons cela en action. Dans notre App.vue fichier, nous effacerions le contenu et le remplacerions par l'extrait ci-dessous:

  

Si vous êtes familier avec Vue.js, ce qui précède ne serait pas nouveau mais pour être complet, ce que nous faisons est de faire une demande d'API en utilisant aller chercher quand notre App.vue est créé, puis nous transmettons les données renvoyées au tableau todos dans notre état de composant. Ensuite, nous utilisons un v-for pour itérer le tableau des todos et afficher la propriété de contenu de chaque todo.

Où est la partie Mirage JS?

Si vous remarquez, dans notre composant App.vue, nous n'avons rien fait de spécifique à Mirage, nous faisons juste un appel API comme nous le ferions normalement. Cette fonctionnalité de Mirage est vraiment géniale pour la cause DX sous le capot, Mirage intercepterait toutes les demandes qui correspondent à l'une des routes définies dans src / server.js pendant que vous êtes en développement.

C'est assez pratique car aucun travail ne serait nécessaire de votre part pour basculer vers un serveur de production réel lorsque vous êtes dans un environnement de production à condition que les routes correspondent à vos points de terminaison d'API de production.

Redémarrez donc votre serveur de développement Vue via fil servir pour tester Mirage JS.

Vous devriez voir une liste de deux todos. Une chose que vous trouveriez assez intéressante est que nous n'avons pas eu besoin d'exécuter une commande de terminal pour démarrer Mirage car elle supprime cette surcharge en s'exécutant dans le cadre de votre application Vue.js.

Utilitaires de test Mirage JS et Vue

Si vous utilisez déjà Vue Test-utils dans votre application Vue, il serait intéressant de savoir que Mirage peut facilement travailler avec lui pour se moquer des demandes du réseau. Voyons un exemple configuré à l'aide de notre application todos.

Nous utiliserions Jest pour nos tests unitaires. Donc, si vous suivez, vous pouvez à peu près utiliser l'interface CLI pour installer le @ vue / unit-jest plugin comme ça:

vue add @ vue / unit-jest

Ce qui précède va installer @ vue / cli-plugin-unit-jest et @ vue / test-utils dépendances de développement tout en créant également un tests répertoire et un jest.config.js fichier. Il ajoutera également la commande suivante dans notre package.json scripts section (assez soignée):

"test: unit": "test vue-cli-service: unit"

Testons!

Nous mettrions à jour notre App.vue ressembler à ceci:


  

Rien de vraiment épique ne se passe dans l'extrait ci-dessus; nous sommes juste en train de structurer pour permettre les tests de réseau que nous implémenterions avec notre test unitaire.

Bien que Vue CLI ait déjà ajouté un / tests dossier pour nous, je trouve que c'est une bien meilleure expérience lorsque mes tests sont placés à proximité des composants qu'ils testent. Alors créez un / __ tests__ dossier dans src / et créer un App.spec.js déposer à l'intérieur. (C'est également l'approche recommandée par Jest.)

// src / __ tests __ / App.spec.js
importer {mount} depuis "@ vue / test-utils"
importer {makeServer} depuis "../server"
importer l'application depuis "../App.vue"

laisser le serveur

beforeEach (() => {
  server = makeServer ({environnement: "test"})
})

afterEach (() => {
  server.shutdown ()
})

Donc, pour configurer nos tests unitaires, nous importons le monter méthode de @ vue / test-utils, en important le serveur Miragejs que nous avons créé précédemment et enfin en important le App.vue composant.

Ensuite, nous utilisons le avantChaque fonction de cycle de vie pour démarrer le serveur Mirage JS tout en passant dans l'environnement de test. (N'oubliez pas, nous définissons par défaut l'environnement développement.)

Enfin, nous fermons le serveur en utilisant server.shutdown dans le après chaque méthode du cycle de vie.

Nos tests

Maintenant, nous allons étoffer notre test (nous adopterions la section de démarrage rapide des documents Mirage js. App.spec.js ressemblerait finalement à ceci:

// src / __ tests __ / App.spec.js

importer {mount} depuis "@ vue / test-utils"
importer {makeServer} depuis "./server"
importer l'application depuis "./App.vue"

laisser le serveur

beforeEach (() => {
  server = makeServer ({environnement: "test"})
})

it ("affiche les todos de notre serveur", async () => {
  server.create ("todo", {id: 1, content: "Learn Mirage JS"})
  server.create ("todo", {id: 2, content: "Integrate with Vue.js"})

  const wrapper = mount (App)

  // attendons que notre composant vue termine le chargement des données
  // nous savons que c'est fait lorsque le data-testid entre dans le dom.
  attendre waitFor (wrapper, '[data-testid="todo-1"]')
  attendre waitFor (wrapper, '[data-testid="todo-2"]')

  attendre (wrapper.find ('[data-testid="todo-1"]') .text ()). toBe ("Learn Mirage JS")
  attendre (wrapper.find ('[data-testid="todo-2"]') .text ()). toBe ("Intégrer avec Vue.js")
})

it ("affiche un message s'il n'y a pas de tâche", async () => {
  // Ne créez aucun todos

  const wrapper = mount (App)
  attendre waitFor (wrapper, '[data-testid="no-todos"]')

  attendre (wrapper.find ('[data-testid="no-todos"]') .text ()). toBe ("Pas de todos!")
})

// Cette méthode d'assistance renvoie une promesse qui résout
// une fois que le sélecteur entre dans le dom du wrapper.
const waitFor = fonction (wrapper, sélecteur) {
  retourner une nouvelle promesse (résoudre => {
    const timer = setInterval (() => {
      const todoEl = wrapper.findAll (sélecteur)
      if (todoEl.length> 0) {
        clearInterval (timer)
        résoudre()
      }
    }, 100)
  })
}

afterEach (() => {
  server.shutdown ()
})

Remarque: Nous utilisons ici un assistant (tel que défini dans les documents Mirage JS). Il renvoie une promesse qui nous permet de savoir quand les éléments que nous testons sont déjà dans le DOM.

Maintenant, lancez test de fil: unité.

Tous vos tests devraient réussir à ce stade.

Test de différents états de serveur avec Mirage JS

Nous pourrions modifier notre serveur Mirage JS pour tester différents états de serveur. Voyons comment.

// src / __ tests __ / App.spec.js
importer {Response} depuis "miragejs"

Tout d'abord, nous importons le Réponse de Mirage, puis nous créons un nouveau scénario de test comme ceci:

il ("gère les réponses d'erreur du serveur", async () => {
  // Remplace le gestionnaire de route de Mirage pour / todos, juste pour ce test
  server.get ("/ todos", () => {
    retourner une nouvelle réponse (
      500,
      {},
      {
        erreur: "La base de données fait une pause.",
      }
    )
  })

  const wrapper = mount (App)

  attendre waitFor (wrapper, '[data-testid="server-error"]')

  attendre (wrapper.find ('[data-testid="server-error"]') .text ()). toBe (
    "La base de données fait une pause."
  )
})

Exécutez votre test et tout devrait réussir.

Conclusion

Cet article avait pour but de vous présenter Mirage JS et de vous montrer comment il améliore l'expérience de développement front-end. Nous avons vu le problème que Mirage JS a créé pour résoudre (créer un front-end prêt pour la production sans aucune API backend réelle) et comment le configurer avec Vue.js.

Bien que cet article ait effacé la surface de ce que Mirage JS peut faire, je pense qu'il suffit de vous aider à démarrer.

  • Vous pouvez parcourir les documents et rejoindre le serveur de discordance Mirage JS.
  • Le référentiel de prise en charge de cet article est disponible sur GitHub.

Les références

Smashing Editorial
(dm, il)