Это тривиальный пример, который иллюстрирует суть моей проблемы:

var innerLib = require('./path/to/innerLib');

function underTest() {
    return innerLib.doComplexStuff();
}

module.exports = underTest;

Я пытаюсь написать модульный тест для этого кода. Как я могу смоделировать требование для innerLibбез макетирования requireфункции полностью?

Так что это я пытаюсь смоделировать глобальное requireи выяснить, что это не сработает даже для этого:

var path = require('path'),
    vm = require('vm'),
    fs = require('fs'),
    indexPath = path.join(__dirname, './underTest');

var globalRequire = require;

require = function(name) {
    console.log('require: ' + name);
    switch(name) {
        case 'connect':
        case indexPath:
            return globalRequire(name);
            break;
    }
};

Проблема в том, что requireфункция внутри underTest.jsфайла фактически не была отключена. Это все еще указывает на глобальную requireфункцию. Таким образом, кажется, что я могу смоделировать requireфункцию только в том же файле, в котором выполняю макетирование . Если я использую глобальный элемент requireдля включения чего-либо, даже после того, как я переопределил локальную копию, требуемые файлы по-прежнему будут иметь глобальная requireссылка.

Ты можешь сейчас!

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

Это означает, что вам не нужно никаких изменений в вашем коде , чтобы внедрить макеты для необходимых модулей.

Proxyquire имеет очень простой API, который позволяет определить модуль, который вы пытаетесь протестировать, и передать макеты / заглушки для необходимых модулей за один простой шаг.

@Raynos прав, что традиционно вам приходилось прибегать к не очень идеальным решениям, чтобы достичь этого, или вместо этого заниматься разработкой снизу вверх.

Который является главной причиной, по которой я создал proxyquire - чтобы позволить разработку сверху вниз без каких-либо хлопот.

Посмотрите документацию и примеры, чтобы оценить, соответствует ли она вашим потребностям.

Лучшим вариантом в этом случае является макет методов возвращаемого модуля.

Что бы там ни было, большинство модулей node.js являются одиночными; две части кода, которые требуют () одного и того же модуля, получают одинаковую ссылку на этот модуль.

Вы можете использовать это и использовать что-то вроде sinon, чтобы макетировать предметы, которые требуются. Мокко тест следующим образом:

// in your testfile
var innerLib  = require('./path/to/innerLib');
var underTest = require('./path/to/underTest');
var sinon     = require('sinon');

describe("underTest", function() {
  it("does something", function() {
    sinon.stub(innerLib, 'toCrazyCrap').callsFake(function() {
      // whatever you would like innerLib.toCrazyCrap to do under test
    });

    underTest();

    sinon.assert.calledOnce(innerLib.toCrazyCrap); // sinon assertion

    innerLib.toCrazyCrap.restore(); // restore original functionality
  });
});

Sinon имеет хорошую интеграцию с chai для создания утверждений, и я написал модуль для интеграции sinon с mocha, чтобы упростить очистку от шпионов / заглушек (чтобы избежать загрязнения тестом.)

Обратите внимание, что underTest нельзя смоделировать таким же образом, поскольку underTest возвращает только функцию.

Другой вариант - использовать шутки. Следите за их страницей

Я использую макет-требуют . Убедитесь, что вы определили свои макеты перед requireтем, как тестировать модуль.

Насмешка requireкажется мне отвратительным. Я лично попытался бы избежать этого и реорганизовать код, чтобы сделать его более тестируемым. Существуют различные подходы для обработки зависимостей.

1) передать зависимости в качестве аргументов

function underTest(innerLib) {
    return innerLib.doComplexStuff();
}

Это сделает код универсально тестируемым. Недостатком является то, что вам нужно передавать зависимости, что может сделать код более сложным.

2) реализовать модуль как класс, затем использовать методы / свойства класса для получения зависимостей

(Это надуманный пример, где использование классов нецелесообразно, но оно передает идею) (пример ES6)

const innerLib = require('./path/to/innerLib')

class underTestClass {
    getInnerLib () {
        return innerLib
    }

    underTestMethod () {
        return this.getInnerLib().doComplexStuff()
    }
}

Теперь вы можете легко заглушить getInnerLibметод для проверки вашего кода. Код становится более подробным, но также и более простым для тестирования.

Если вы когда-либо использовали шутку, то вы, вероятно, знакомы с шутливой функцией шутки.

Используя "jest.mock (...)", вы можете просто указать строку, которая будет встречаться в операторе require где-нибудь в вашем коде, и всякий раз, когда требуется модуль, использующий эту строку, вместо этого будет возвращен mock-объект.

Например

jest.mock("firebase-admin", () => {
    const a = require("mocked-version-of-firebase-admin");
    a.someAdditionalMockedMethod = () => {}
    return a;
})

полностью заменит все операции импорта / требования «firebase-admin» на объект, который вы вернули из этой «фабричной» функции.

Что ж, вы можете сделать это при использовании jest, потому что jest создает среду выполнения для каждого запускаемого модуля и внедряет в модуль «зацепленную» версию require, но вы не сможете сделать это без jest.

Я пытался достичь этого с помощью mock-require, но для меня это не сработало для вложенных уровней в моем источнике. Посмотрите на следующую проблему на github: mock-require не всегда вызывается с Mocha .

Для решения этой проблемы я создал два npm-модуля, которые вы можете использовать для достижения желаемого.

Вам нужен один babel-плагин и модуль-макер.

• столпотворение-плагин-макет требует
• jestlike-макет

В вашем .babelrc используйте плагин babel-plugin-mock-require со следующими параметрами:

...
"plugins": [
        ["babel-plugin-mock-require", { "moduleMocker": "jestlike-mock" }],
        ...
]
...

и в вашем тестовом файле используйте модуль jestlike-mock следующим образом:

import {jestMocker} from "jestlike-mock";
...
jestMocker.mock("firebase-admin", () => {
            const firebase = new (require("firebase-mock").MockFirebaseSdk)();
            ...
            return firebase;
});
...

jestlike-mockМодуль еще очень рудиментарный и не имеет много документации , но там не много кода либо. Я ценю любые PR для более полного набора функций. Цель состоит в том, чтобы воссоздать всю функцию "jest.mock".

Чтобы увидеть, как jest реализует это, можно посмотреть код в пакете "jest-runtime". См., Например, https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js#L734 , здесь они генерируют «автоматическую блокировку» модуля.

Надеюсь, это поможет ;)

Ты не можешь Вы должны создать свой набор модульных тестов так, чтобы сначала тестировались самые младшие модули, а потом - модули более высокого уровня, для которых требуются модули.

Вы также должны предположить, что любой сторонний код и сам node.js хорошо протестированы.

Я полагаю, вы увидите, что в ближайшем будущем появятся насмешливые рамки, которые перезаписывают global.require

Если вам действительно нужно внедрить макет, вы можете изменить свой код, чтобы открыть модульную область видимости.

// underTest.js
var innerLib = require('./path/to/innerLib');

function underTest() {
    return innerLib.toCrazyCrap();
}

module.exports = underTest;
module.exports.__module = module;

// test.js
function test() {
    var underTest = require("underTest");
    underTest.__module.innerLib = {
        toCrazyCrap: function() { return true; }
    };
    assert.ok(underTest());
}

Имейте в виду, что это подвергает риску .__moduleваш API, и любой код может получить доступ к модульной области на свою собственную опасность.

Вы можете использовать издевательскую библиотеку:

describe 'UnderTest', ->
  before ->
    mockery.enable( warnOnUnregistered: false )
    mockery.registerMock('./path/to/innerLib', { doComplexStuff: -> 'Complex result' })
    @underTest = require('./path/to/underTest')

  it 'should compute complex value', ->
    expect(@underTest()).to.eq 'Complex result'

Простой код для макетов модулей для любопытных

Обратите внимание на части, где вы манипулируете require.cacheи обратите внимание на require.resolveметод, поскольку это секретный соус.

class MockModules {  
  constructor() {
    this._resolvedPaths = {} 
  }
  add({ path, mock }) {
    const resolvedPath = require.resolve(path)
    this._resolvedPaths[resolvedPath] = true
    require.cache[resolvedPath] = {
      id: resolvedPath,
      file: resolvedPath,
      loaded: true,
      exports: mock
    }
  }
  clear(path) {
    const resolvedPath = require.resolve(path)
    delete this._resolvedPaths[resolvedPath]
    delete require.cache[resolvedPath]
  }
  clearAll() {
    Object.keys(this._resolvedPaths).forEach(resolvedPath =>
      delete require.cache[resolvedPath]
    )
    this._resolvedPaths = {}
  }
}

Используйте как :

describe('#someModuleUsingTheThing', () => {
  const mockModules = new MockModules()
  beforeAll(() => {
    mockModules.add({
      // use the same require path as you normally would
      path: '../theThing',
      // mock return an object with "theThingMethod"
      mock: {
        theThingMethod: () => true
      }
    })
  })
  afterAll(() => {
    mockModules.clearAll()
  })
  it('should do the thing', async () => {
    const someModuleUsingTheThing = require('./someModuleUsingTheThing')
    expect(someModuleUsingTheThing.theThingMethod()).to.equal(true)
  })
})

НО ... Proxyquire довольно круто, и вы должны использовать это. Он сохраняет ваши требования переопределенными только для тестов, и я настоятельно рекомендую это сделать.