Comment l'unité de test express Routeur routes

Je suis nouveau sur le Nœud et de l'Exprimer et je suis en train de test de l'unité de mes itinéraires/contrôleurs. J'ai séparé mes itinéraires de mes contrôleurs. Comment puis-je tester mes itinéraires?

config/express.js

  var app = express();
  //middleware, etc
  var router = require('../app/router')(app);

app/router/index.js

  module.exports = function(app) {
    app.use('/api/books', require('./routes/books'));
  };

app/router/routes/books.js

  var controller = require('../../api/controllers/books');
  var express = require('express');
  var router = express.Router();

  router.get('/', controller.index);

  module.exports = router;

app/api/controllers/books.js

//this is just an example controller
exports.index = function(req, res) {
    return res.status(200).json('ok');
};

app/tests/api/routes/books.test.js

  var chai = require('chai');
  var should = chai.should();
  var sinon = require('sinon');

  describe('BookRoute', function() {

  });

Double Possible de Comment fonctionne une unité itinéraires de test avec Express?
Pas un doublon, liés question est de plus Express qui avait une API différente.
Utiliser ce Lien ou le Lien.
Outre les liens qui vous est donnée par @PraveshKhatri, vous voudrez peut-être jeter un oeil à la chai-http plugin
Je ne voudrais pas écrire des tests unitaires pour les routes. Garder les voies de la logique-moins. Votre logique à l'écart de la routes & écrire des tests unitaires pour eux. Fonctionnelle ou de tests d'intégration peut être ajouté pour les routes.
Je suis entièrement d'accord avec @xyz. Séparer votre logique à partir de vos points et vous serez en mesure de tester pleinement sans avoir à utiliser supertest (ou équivalents).
Il y a des tests sur des routes qui s'applique uniquement aux itinéraires. Donc, en disant: "une logique à l'écart de la route" n'est pas réellement résoudre le problème. Elle réduit au minimum, mais les routes nécessitent encore des tests, de l'OMI. Vous pourriez accidentellement lier le mauvais appel à un itinéraire. Vous pourriez avoir une faute de frappe dans l'itinéraire. Donc, il est encore "pure" liées à l'itinéraire de code de test qui est spécifique à votre application, de l'OMI.

InformationsquelleAutor cusejuice | 2016-02-05

Code:

config/express.js

var app = express();
//middleware, etc
var router = require('../app/router')(app);

module.exports = app;

app/tests/api/routes/books.test.js

var chai = require('chai');
var should = chai.should();
var sinon = require('sinon');
var request = require('supertest');
var app = require('config/express');

describe('BookRoute', function() {
    request(app)
        .get('/api/books')
        .expect('Content-Type', /json/)
        .expect('Content-Length', '4')
        .expect(200, "ok")
        .end(function(err, res){
           if (err) throw err;
        });
});

Considérations:

Si votre serveur nécessite un état initial au début d'un ensemble de tests (parce que vous êtes à l'exécution des appels qui mutent de l'état du serveur), vous aurez besoin d'écrire une fonction qui retourne un fraîchement configuré application et le début de chaque groupe de tests. Il y a un mécanisme national de prévention de la bibliothèque: https://github.com/bahmutov/really-need qui va vous permettre d'exiger un fraîchement instancié de la version de votre serveur.

InformationsquelleAutor ironchefpython

4

C'est intéressant parce que vous avez séparé vos contrôleurs de vos routeurs. Les autres StackOverflow l'article mentionné dans les commentaires est un bon moyen de tester vos contrôleurs, je pense. La chose à garder à l'esprit avec des tests unitaires est ce que vous êtes de test exactement. Vous ne devriez pas besoin d'écrire des tests pour tester l'express bibliothèque parce qu'il a ses propres tests unitaires. Donc, vous avez juste besoin de tester vos appels à la bibliothèque. Donc, pour les livres de route, vous avez juste besoin de tester cette ligne de code:
```
router.get('/', controller.index);
```
J'ai regardé autour pour voir si il y avait un moyen évident pour obtenir une liste des routes à partir de l'express de la bibliothèque, mais je n'ai pas vu un seul. Vous pouvez probablement juste de regarder la bibliothèque elle-même et vérifier son fonctionnement interne pour voir si vous définissez un itinéraire correctement. Une autre option est bien pour s'en moquer et il suffit de vérifier que vous êtes en l'appelant correctement.

Cela va être assez compliqué parce que vous avez besoin pour se moquer d'un certains des éléments fondamentaux de Javascript afin de tester cette ligne de code. Voici comment je l'ai fait:
```
describe('BookRoute', function() {
  it("should route /to books controller index", function() {
    var controller = require('../../../api/controllers/books');
    var orig_this = this;
    var orig_load = require('module')._load;
    var router = jasmine.createSpyObj('Router', ['get']);
    var express = jasmine.createSpyObj('express', ['Router']);
    express.Router.and.returnValues(router);
    spyOn(require('module'), '_load').and.callFake(function() {
      if (arguments[0] == 'express') {
        return express;
      } else {
        return orig_load.apply(orig_this, arguments);
      }
    });
    require("../../../router/routes/books");
    expect(router.get).toHaveBeenCalledWith('/', controller.index);
  });
});
```
Ce qui se passe ici est que je l'habitude de Jasmine spyOn fonction de spyOn la _load fonction dans module.js qui est-ce qui s'occupe de toutes les exiger des appels. C'est ainsi que lorsque nous avons besoin de livres routeur et qu'il appelle require('express'), nous pouvons retourner à nos exprimer SpyObj que nous avons créé avec le jasmin.createSpyObj. Une fois que nous avons remplacé exprimer avec notre espion objet, alors nous pouvons avoir de retour de notre Routeur SpyObj qui va nous permettre de spy sur le routeur.obtenir. Nous pouvons alors assurez-vous qu'il est appelé avec un '/' et le contrôleur.index.

Cela pourrait être fait dans une sorte d'utilitaire si vous voulais l'utiliser beaucoup.

J'ai l'habitude d'éviter beaucoup de cette chose par la à l'aide d'une approche orientée objet et soit je suis de passage autour de certains objets partout que je peux fantaisie pour les tests ou vous pouvez utiliser un certain type de l'injection de dépendance comme Angulaire utilise.

InformationsquelleAutor Peter Haight
2

J'ai trouvé ce blog incroyablement perspicace lors de l'essai de mes propres serveurs de points de terminaison.

Dans le blog, il s'adresse:
- Comment utiliser le point de terminaison bibliothèque de test supertest.
- Procédure de programmation pour le spin et le démontage de l'express server avec votre besoin de voies avant et après chaque point de terminaison de test. (il explique également pourquoi vous voulez le faire).
- Comment éviter un piège, nécessitent la mise en cache de vos modules requis dans vos tests unitaires, conduisant à des conséquences inattendues.
Espère que cette aide. Bonne chance et si vous avez des questions, laissez-moi savoir.
- Le blog point a de beaux exemples sur la façon d'utiliser supertest pour tester l'API points de terminaison. Cependant, je pense que certains commentaires sont nécessaires comme je ne suis pas entièrement d'accord avec l'auteur. Démarrage et arrêt du serveur entre chaque test est une mauvaise conception. Si c'est une API RESTful vous testez le serveur doit être apatride, de toute façon. Si c'est une application avec l'état, vous risquez de détruire la session entre chaque essai pour atteindre le même. Aussi, il semble que l'auteur ne comprend pas comment la Pile JavaScript œuvres qui le conduit à des conclusions incorrectes.
InformationsquelleAutor Patrick Motard

Vous devez vous connecter pour publier un commentaire.