Grunt-Test-API mit Supertest, Express und Mokka

Question

Ich habe einen https-Server, der per Express läuft, den ich mit Mocha und Supertest teste.

Mein Problem ist: Wenn ich nur den Test durchführe, ist alles in Ordnung.Wenn ich versuche, Gruntfile mit Test auszuführen, dann führe ich Express aus – ich sehe viele EADDRINUSE-Fehler, auch wenn ich in Testdateien after() mit app.close() mache.Das Gleiche gilt für die Überwachungsaufgabe bei Tests.

Hier ist mein Beispieltest:

/* 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();
            });
        });
    });

}());

Mir ist bewusst, dass diese Tests alles andere als perfekt sind.Ich beginne mein Abenteuer gerade erst mit dem richtigen Softwaretesten.

All diese „bereits verwendeten Ports“ sind offensichtlich, und keiner davon ...Geben Sie ein Problem.Alle Tests funktionieren gut, der Server funktioniert gut, aber Standardausgabe ist verrückt.Ein solches Verhalten ist alles andere als ideal und wahrscheinlich voller potenzieller Probleme und Instabilitätsprobleme.

Meine Frage ist: Wie werde ich es los?

Meine Ideen sind:

• Erstellen Sie einen dedizierten Server zum Testen auf einem anderen Port.Leider habe ich keine Ahnung, wie ich das umsetzen soll.

• Machen Sie eine Bedingung dafür, dass der Superagent den Server ausführt, wenn er nicht ausgeführt wird, oder einfach ...Sonst an Superagent weitergeben?

• Verwenden Sie etwas anderes als Superagent (z. B. Anfrage, aber ich bin mir nicht sicher, ob alle Cookies und node_tls_reject_unauthorized funktionieren würden.

Wie Sie sehen, habe ich Probleme mit diesem Thema und habe mehr Fragen als Antworten und nicht genug Erfahrung, um zu wissen, wo ich nachschauen soll.

Ich freue mich über jede Hilfe.

BEARBEITEN:

Ich habe herausgefunden, dass ich Folgendes tun kann:

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

was den Test an einem anderen Port startet, aber ...Die gesamte server.js wird sowieso geladen, also startet sie trotzdem.Wenn es dann zusammen mit dem laufenden Server gestartet wird, gibt es offensichtlich EADDRINUSE.

Answer 1

Beim Benutzen superagent, sollten Sie ihm immer eine Express-Anwendung übergeben, die konfiguriert wurde (Middleware registriert, Controller geroutet usw.), aber nicht als HTTP-Server initialisiert wurde.Es wird das für Sie tun und es wird es aufschieben http.createServer, an das Betriebssystem, um einen verfügbaren Port auszuwählen.

Wenn Sie das derzeit haben server.js Wenn das Modul bereits eine statische Instanz eines vollständigen HTTP-Servers bereitstellt, ist dies höchstwahrscheinlich die Ursache Ihrer Probleme.Versuchen Sie in jedem Fall, die Anwendungskonfiguration/das Bootstrapping wie folgt aus der tatsächlichen Serverinstanziierung zu extrahieren:

// 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);

Dann können Sie in Ihren Tests etwas in der Art tun:

// 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
        });
    });
});

Dies dient nur zur Veranschaulichung, da das Wann/Wie der Instanziierung der Anwendungsinstanz von Ihrem Testkontext abhängt.Wichtig ist, dass Sie in der Lage sein sollten, neue, saubere, unabhängige und isolierte Serverinstanzen für Ihre Testfälle zu erstellen.Dies ist unbedingt erforderlich, wenn Sie einen Testläufer verwenden, der Tests parallel oder in zufälliger Reihenfolge ausführt.