URL-адреса модульного тестирования Nodejs

Question

Каков наилучший способ сделать это постепенно? Например. Некоторые URL-адреса должны быть доступны прежде, чем другие заполнят БД и т. Д. Существует ли идиоматический узел для модульного тестирования?

В настоящее время я считываю данные модульного теста из файла json, а затем запрашиваю на основе этого.

function urlTestFn(test){
    var req = requestProperties(test);
    var request = http.request(req, function(resp) {
        resp.setEncoding('utf8');
        resp.on('data',function(data) {
            if(data == JSON.stringify(test.response)) {
                //success
            } else {
                sys.puts('fail');
            }
        });
    });
    if(req.method == 'POST'){
        request.write(JSON.stringify(test.postData));
    }
    request.end();
}

Answer 1

В дополнение к совету Питера Линоса позвольте мне представить вам правильную идею модульного тестирования. При выполнении модульного тестирования многие люди задают не тот вопрос. Это не «Как я проверяю это», а «Что я проверяю». В вашем случае вы хотите проверить свой код, логику и ничего больше. Это означает, что вы должны удалить все внешние факторы, включая сторонние библиотеки, модули npm и даже основные модули API node.js.

Задайте себе вопрос: можете ли вы скопировать свой набор тестов и запустить его, не тратя часы на настройку среды? Ты должен быть способен. В этом весь смысл написания модульных тестов - заставить их работать изолированно, чтобы гарантировать правильность кода. Мы называем эту «среду», в которой ваш код может работать изолированно, «контрольной средой», аналогично тому, что используется в научных кругах.

Теперь, чтобы достичь этого, вам нужно понять концепцию светильников и макетов. Светильники предназначены для создания вашей среды управления. Это достигается созданием группы фиктивных объектов, где каждый фиктивный объект принимает входные данные и создает выходные данные. Таким образом, у вас есть точный контроль над всеми аспектами вашего кода, и это упрощает тестирование всех видов вещей, от операций с БД до запросов REST.

Наконец, поняв, что:

1. Лучший набор тестов - это тот, который может работать в изолированной контрольной среде
2. Светильники используются для создания этой среды, предоставляя вашему коду фиктивные объекты
3. Имитируемые объекты принимают входные данные и возвращают выходные данные
4. Выше 3 вещи могут быть достигнуты только в том случае, если вы закодировали свой проект со 100% -ной зависимостью

Макет объектов

Предполагая, что в вашей функции foo () вы хотите прочитать содержимое файла, вот как должен выглядеть ваш макет:

var FsMock = {
    readFile : function readFile(path, encoding, callback) {
        if (path === 'unit-test-1')
            callback(null, 'This is the file contents');
        else
            callback(new Error('Unexpected error');
    }
}

А затем в своем тестовом коде вы пытаетесь прочитать файл «unit-test-1», и он вернет «Это содержимое файла».

Внедрение зависимостей

Все вышеперечисленное было бы чрезвычайно сложно, если бы ваш проект не был написан так, чтобы его зависимости вводились извне. В настоящее время мое соглашение состоит в том, что все модули должны иметь функцию make (), которая принимает объект, содержащий все его зависимости. Вот простой пример:

var Fs = null;
var Path = null;

var TestObj = module.exports = {
    make : function make(args) {
        if ('undefined' === typeof args.fs)
            throw new Error('Dependency: FS module needed');
        if ('undefined' === typeof args.path)
            throw new Error('Dependency: Path module needed');

        Fs = args.fs;
        Path = args.fs;

        return Object.create(this);
    }
}

Тогда вам понадобится либо фабрика, либо DI-контейнер, чтобы построить этот объект для вас, автоматически создавая его зависимости.

Только тогда BDD и TDD будут интересны в вашем проекте. Надеюсь, это поможет!

Answer 2

ОК, несколько советов.Ваш код, похоже, не использует какую-либо тестовую среду, поэтому посмотрите хотя бы на использование CommonJS-утверждений или инфраструктуры тестирования.Я предпочитаю жасмин , но есть несколько хороших.Жасмин прекрасно поддерживает шпионов и асинхронные тесты.Как побочный комментарий, это не модульные тесты, которые по определению не попадут в базу данных, скорее всего, это тесты приложений / системы.Возможно, вы захотите написать несколько чистых модульных тестов для кода на стороне сервера в дополнение к этим тестам системного уровня, которые отправляют живые данные через весь стек.

По теме предварительных условий тестирования, как правило, старайтесь выполнять каждый тестнастолько независимым, насколько это возможно.Но когда полной независимости не избежать, большинство структур модульного тестирования имеют концепцию пары функций setup / teardown, которые вызываются до и после каждого теста.В жасмин это функция beforeEach.Предварительная загрузка объектов БД в качестве «фикстур» иногда выполняется в сообществе Rails.Существует также понятие «фабрики».У каждой стратегии есть свои сильные и слабые стороны.Я не уверен, есть ли библиотеки узлов для фабрик или приборов, но делаю поиск в Интернете.