Este es un ejemplo trivial que ilustra el quid de mi problema:

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

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

module.exports = underTest;

Estoy tratando de escribir una prueba unitaria para este código. ¿Cómo puedo burlarme del requisito para el innerLibsin burlar completamente la requirefunción?

Así que este soy yo tratando de burlarme de lo global requirey descubriendo que no funcionará incluso para hacer eso:

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

El problema es que la requirefunción dentro del underTest.jsarchivo en realidad no se ha burlado. Todavía apunta a la requirefunción global . Por lo tanto, parece que solo puedo requiresimular la función dentro del mismo archivo en el que estoy haciendo el simulacro . Si uso el global requirepara incluir algo, incluso después de haber anulado la copia local, los archivos requeridos seguirán teniendo requirereferencia global

¡Tu puedes ahora!

Publiqué proxyquire que se encargará de anular el mundial requieren dentro de su módulo mientras se está probando la misma.

Esto significa que no necesita cambios en su código para inyectar simulacros para los módulos requeridos.

Proxyquire tiene una API muy simple que permite resolver el módulo que está tratando de probar y pasar simulaciones / apéndices para sus módulos requeridos en un solo paso simple.

@Raynos tiene razón en que tradicionalmente tenía que recurrir a soluciones no muy ideales para lograr eso o hacer un desarrollo ascendente

Cuál es la razón principal por la que creé proxyquire: para permitir el desarrollo de prueba de arriba hacia abajo sin ninguna molestia.

Eche un vistazo a la documentación y los ejemplos para determinar si se ajusta a sus necesidades.

Una mejor opción en este caso es burlarse de los métodos del módulo que se devuelve.

Para bien o para mal, la mayoría de los módulos node.js son singletons; dos piezas de código que requieren () el mismo módulo obtienen la misma referencia a ese módulo.

Puede aprovechar esto y usar algo como sinon para burlarse de los elementos que se requieren. prueba de moca sigue:

// 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 tiene una buena integración con chai para hacer afirmaciones, y escribí un módulo para integrar sinon con mocha para permitir una limpieza más fácil de espías / trozos (para evitar la contaminación de prueba).

Tenga en cuenta que underTest no se puede burlar de la misma manera, ya que underTest solo devuelve una función.

Otra opción es usar simulacros de Jest. Seguimiento en su página

Yo uso simulacro de requerimiento . Asegúrese de definir sus simulacros antes requiredel módulo que se probará.

Burlarse me requireparece un truco desagradable. Yo personalmente trataría de evitarlo y refactorizar el código para hacerlo más comprobable. Hay varios enfoques para manejar las dependencias.

1) pasar dependencias como argumentos

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

Esto hará que el código sea universalmente comprobable. La desventaja es que necesita pasar dependencias, lo que puede hacer que el código se vea más complicado.

2) implementar el módulo como una clase, luego usar métodos / propiedades de clase para obtener dependencias

(Este es un ejemplo artificial, donde el uso de la clase no es razonable, pero transmite la idea) (ejemplo ES6)

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

class underTestClass {
    getInnerLib () {
        return innerLib
    }

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

Ahora puede tropezar fácilmente el getInnerLibmétodo para probar su código. El código se vuelve más detallado, pero también más fácil de probar.

Si alguna vez has usado jest, entonces probablemente estés familiarizado con la función simulada de jest.

Usando "jest.mock (...)" simplemente puede especificar la cadena que ocurriría en una declaración require en su código en algún lugar y cada vez que se requiera un módulo usando esa cadena se devolvería un objeto simulado.

Por ejemplo

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

reemplazaría por completo todas las importaciones / requisitos de "firebase-admin" con el objeto que devolvió de esa función "fábrica".

Bueno, puede hacer eso cuando usa jest porque jest crea un tiempo de ejecución alrededor de cada módulo que ejecuta e inyecta una versión "enganchada" de require en el módulo, pero no podría hacerlo sin jest.

He intentado lograr esto con simulacro de requerimiento, pero para mí no funcionó para niveles anidados en mi fuente. Eche un vistazo al siguiente problema en github: mock-require no siempre se llama con Mocha .

Para abordar esto, he creado dos módulos npm que puede usar para lograr lo que desea.

Necesita un plugin de babel y un burlador de módulos.

• babel-plugin-mock-require
• burlona

En su .babelrc use el complemento babel-plugin-mock-require con las siguientes opciones:

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

y en su archivo de prueba use el módulo jestlike-mock de esta manera:

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

El jestlike-mockmódulo sigue siendo muy rudimentario y no tiene mucha documentación, pero tampoco hay mucho código. Agradezco cualquier RP para un conjunto de características más completo. El objetivo sería recrear toda la función "jest.mock".

Para ver cómo implementa jest, se puede buscar el código en el paquete "jest-runtime". Ver https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js#L734 por ejemplo, aquí generan un "bloqueo automático" de un módulo.

Espero que ayude ;)

No puedes Debe construir su conjunto de pruebas unitarias para que los módulos más bajos se prueben primero y los módulos de nivel superior que requieren módulos se prueben después.

También debe suponer que cualquier código de terceros y node.js en sí está bien probado.

Supongo que en un futuro próximo verán marcos burlones que sobrescribirán global.require

Si realmente debe inyectar un simulacro, puede cambiar su código para exponer el alcance modular.

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

Tenga en cuenta que esto se expone .__moduleen su API y cualquier código puede acceder al alcance modular bajo su propio riesgo.

Puedes usar la biblioteca de burlas :

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'

Código simple para burlarse de módulos para curiosos

Observe las partes donde manipula el método require.cachey nota require.resolveya que esta es la salsa secreta.

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 = {}
  }
}

Usar como :

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

PERO ... proxyquire es bastante impresionante y deberías usar eso. Mantiene sus anulaciones requeridas localizadas solo para pruebas y lo recomiendo encarecidamente.