Struktur für Komponententests auf node.js mit Mungo

Question

Ich habe mit node.js seit Monaten entwickelt, aber jetzt fange ich ein neues Projekt an und ich würde gerne wissen, wie man die App strukturiert.

Mein Problem kommt, wenn ich über Komponententests spreche. Ich werde nodeunit verwenden, um Komponententests zu schreiben.

Auch ich benutze Express, um meine REST-Routen zu definieren.

Ich dachte darüber nach, meinen Code zu schreiben, der auf Datenbanken in zwei "separaten" Dateien zugreift (Sie werden natürlich mehr sein, aber ich versuche nur, den Code zu vereinfachen). Es wird den Routencode geben.

var mongoose = require('mongoose') 
, itemsService = require('./../../lib/services/items-service'); 

// GET '/items' 
exports.list = function(req, res) { 
    itemsService.findAll({ 
     start: req.query.start, 
     size: req.query.size, 
     cb: function(offers) { 
      res.json(offers); 
     } 
    }); 
    }; 

Und, wie ich dort verwende, ein Element-Service nur für den Zugriff auf die Datenebene verwendet. Ich tue das, um nur die Datenzugriffsebene beim Komponententest zu testen. Es wird so etwas wie diese:

var mongoose = require('mongoose') 
    , Item = require('./../mongoose-models').Item; 

exports.findAll = function(options) { 
    var query = Offer 
     .find({}); 
    if (options.start && options.size) { 
     query 
      .limit(size) 
      .skip(start) 
    } 
    query.exec(function(err, offers) { 
     if (!err) { 
       options.cb(offers); 
      } 
    }) 
}; 

So kann ich mit Unit-Tests prüfen, ob es korrekt funktioniert und ich kann diesen Code verwenden überall ich will. Das einzige, was ich nicht sicher bin, ob es richtig gemacht wurde, ist die Art, wie ich eine Callback-Funktion übergebe, um den zurückgegebenen Wert zu verwenden.

Was denkst du?

Danke!

Answer 1

Ja, ganz einfach! Sie können ein Einheitentestmodul wie mocha und einen eigenen oder einen anderen Knoten verwenden, z. B. should.

Als Beispiel für einen Testfall für Ihr Beispiel Modell:

var ItemService = require('../../lib/services/items-service'); 
var should = require('should'); 
var mongoose = require('mongoose'); 

// We need a database connection 
mongoose.connect('mongodb://localhost/project-db-test'); 

// Now we write specs using the mocha BDD api 
describe('ItemService', function() { 

    describe('#findAll(options)', function() { 

    it('"args.size" returns the correct length', function(done) { // Async test, the lone argument is the complete callback 
     var _size = Math.round(Math.random() * 420)); 
     ItemService.findAll({ 
     size : _size, 
     cb : function(result) { 
      should.exist(result); 
      result.length.should.equal(_size); 
      // etc. 

      done(); // We call async test complete method 
     } 
     }, 
    }); 


    it('does something else...', function() { 

    }); 

    }); 

}); 

Und so weiter, bis zum Überdruss.

Dann, wenn Sie Ihre Tests fertig sind schriftlich - vorausgesetzt, Sie haben $ npm install mocha ‚d - dann würden Sie einfach $ ./node_modules/.bin/mocha oder $ mocha ausführen, wenn Sie NPMs Option -g verwendet.

Hängt davon ab, wie rectal/detailliert Sie wirklich sein wollen. Ich wurde immer darauf hingewiesen und finde es einfacher: Schreiben Sie zuerst die Tests, um eine klare Spezifikationsperspektive zu erhalten. Dann schreiben Sie die Implementierung gegen die Tests, mit jedem zusätzlichen Einblick ein Freebie.