API de test de grognement avec supertest, express et moka

Question

J'ai un serveur https fonctionnant par express, que je teste avec moka et supertest.

Mon problème est que si je lance uniquement le test, tout va bien.Si j'essaie d'exécuter gruntfile avec test, puis d'exécuter express - je vois beaucoup d'erreurs EADDRINUSE, même si dans les fichiers de test je fais after() avec app.close().Il en va de même pour la tâche de surveillance lors des tests.

Voici mon exemple de test :

/* jshint node: true*/
/*global describe, it, after*/
(function() {
    'use strict';
    process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
    var request = require('supertest');
    var app = require('../server.js').app;
    var expect = require('chai').expect;
    var Cookies;

    after(function(done) {
        app.close();
        setTimeout(function(){done();}, 1500);
    });

    describe('/login', function() {
        it('should auth the user', function(done) {
            request(app)
                .post('/login')
                .send({login: "test", password: 'test'})
                .expect(302)
                .end(function(err, res) {
                    expect(err).to.be.equal(null);
                    expect(res.text).to.be.equal("Moved Temporarily. Redirecting to /");
                    Cookies = res.headers['set-cookie'].pop().split(';')[0];
                    done();
            });

        });
    });
    // testing API for serving session data for angualar factory
    describe('/api/session', function() {
        it('should return session data in JSON', function(done) {
            var req = request(app).get('/api/session');             
                req.cookies = Cookies;
                req.set('Accept','application/json')
                .end(function(err, res) {
                    expect(err).to.be.equal(null);
                    expect(res.body).to.have.property("_id");
                    done();
            });
        });
    });

}());

Je suis conscient que ces tests sont loin d'être parfaits.Je viens tout juste de commencer mon aventure avec des tests logiciels appropriés.

Tous ces "ports déjà utilisés" sont évidents, et aucun d'entre eux...donner n'importe quel problème.tous les tests fonctionnent bien, le serveur fonctionne bien, mais la sortie standard est folle.Un tel comportement est loin d’être idéal et est probablement plein de problèmes potentiels et de problèmes d’instabilité.

Ma question est : comment s'en débarrasser ?

Mes idées sont :

• créez un serveur dédié pour le test sur un port différent uniquement.Malheureusement, je dois savoir comment mettre en œuvre cela.

• imposez des conditions pour que le superagent exécute le serveur s'il n'est pas en cours d'exécution, ou simplement...sinon, passe-le au superagent ?

• utilisez autre chose qu'un superagent (comme request, mais je ne sais pas si tous les cookies et node_tls_reject_unauthorized fonctionneraient.

Comme vous pouvez le voir, j'ai du mal avec ce sujet et j'ai plus de questions que de réponses, et pas assez d'expérience pour savoir où regarder.

J'apprécie gentiment toute aide.

MODIFIER:

J'ai trouvé que je peux faire :

before(function(done) {
    app.listen(3001, function() { done(); });
});

qui démarre le test sur un autre port mais...l'ensemble du server.js est chargé de toute façon, donc il démarre quand même aussi.Ensuite, lors du lancement avec le serveur en cours d'exécution, il y a un EADDRINUSE évident.

Answer 1

Lors de l'utilisation superagent, vous devez toujours lui transmettre une application Express qui a été configurée (middleware enregistré, contrôleurs routés, etc.) - mais non initialisée en tant que serveur HTTP.Il le fera pour vous et il différera, grâce à http.createServer, au système d'exploitation pour choisir un port disponible.

Si vous l'avez actuellement, le server.js Le module fournit déjà une instance statique d'un serveur HTTP à part entière, qui est probablement la source de vos problèmes.Dans les deux cas, essayez d'extraire la configuration/le démarrage de l'application à partir de l'instanciation réelle du serveur, comme ceci :

// server.js
var express = require('express');
var middleware = require('./middleware');
var controllers = require('./controllers');

// Configures the Express application instance.
exports.setup = function (app) {
    app.use(middleware.foo);
    app.get('/bar', controllers.bar);

    app.locals.baz = 'quux';
}

// You might shoot yourself in the foot if parts of your application depend
// on a static reference at `server.app`.
exports.app = setup(express());
exports.app.listen(3000);

Ensuite, dans vos tests, vous pouvez faire quelque chose du genre :

// tests.js
var express = require('express');
var server = require('./server');

describe('Server tests', function () {
    // Create a fresh server instance prior to each test
    beforeEach(function createNewSever() {
        this.app = server.setup(express());
    });

    describe('Foo', function () {
        it('barrs', function () {
            request(this.app)  // initializes a server instance on port A
            // ... supertests
        });

        it('bazzes', function () {
            request(this.app)  // initializes a server instance on port B
            // ... more supertests
        });
    });
});

Ceci est uniquement à des fins d'illustration, où le moment/comment instancier l'instance d'application dépendra de votre contexte de test.La chose importante à retenir est que vous devriez être en mesure de créer des instances de serveur fraîches, propres, indépendantes et isolées pour vos cas de test.C'est une nécessité absolue si vous utilisez un programme d'exécution de tests qui exécute les tests en parallèle ou dans un ordre aléatoire.