Структура для модульного тестирования на node.js с мангустом

Я разрабатывал с помощью node.js в течение нескольких месяцев, но теперь я начинаю новый проект, и я хотел бы знать, как структурировать приложение.

Моя проблема возникает, когда я говорю о модульном тестировании. Я буду использовать nodeunit для написания модульных тестов.

Также я использую экспресс для определения маршрутов REST.

Я думал о том, чтобы написать свой код, который обращается к базам данных в двух «отдельных» файлах (их, очевидно, будет больше, но я просто пытаюсь упростить код). Там будет код маршрута.

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

И, поскольку я использую там службу элементов, используемую только для доступа к слою данных. Я делаю это, чтобы протестировать только уровень доступа к данным при модульном тестировании. Это будет примерно так:

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

Таким образом, я могу проверить с помощью модульного тестирования, правильно ли он работает, и я могу использовать этот код везде, где захочу. Единственное, в чем я не уверен, правильно ли это было сделано, так это в том, как я передаю функцию обратного вызова для использования возвращаемого значения.

Как вы думаете?

Спасибо!


node.js javascript nodeunit
person Javier Manzano    schedule 27.12.2012    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Да запросто! Вы можете использовать модуль модульного тестирования, такой как mocha, а также собственное утверждение узла или другое, например следует.

В качестве примера тестового примера для вашей примерной модели:

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() {

    });

  });

});

И так далее, до тошноты.

Затем, когда вы закончите писать свои тесты, предполагая, что вы выполнили $ npm install mocha, вы просто запустите $ ./node_modules/.bin/mocha или $ mocha, если вы использовали флаг npm -g.

Зависит от того, насколько ректальным/детальным вы хотите быть на самом деле. Мне всегда советовали, и я считаю, что это проще: Сначала написать тесты, чтобы получить четкую перспективу спецификации. Затем напишите реализацию на основе тестов, и любая дополнительная информация будет бесплатной.

person rounce    schedule 29.12.2012
comment
вам нужно подключиться к монго с помощью mongodb://‹host›/‹db› - person binarygiant; 08.07.2013