Questo è un esempio banale che illustra il nocciolo del mio problema:

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

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

module.exports = underTest;

Sto cercando di scrivere un test unitario per questo codice. Come posso deridere il requisito per il innerLibsenza deridere completamente la requirefunzione?

Quindi sono io che sto cercando di deridere il globale requiree scoprire che non funzionerà nemmeno per farlo:

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

Il problema è che la requirefunzione all'interno del underTest.jsfile non è stata effettivamente derisa. Indica ancora la requirefunzione globale . Quindi sembra che posso solo deridere la requirefunzione all'interno dello stesso file in cui sto eseguendo il derisione. Se uso il globale requireper includere qualcosa, anche dopo aver sovrascritto la copia locale, i file richiesti avranno comunque il requireriferimento globale .

Tu puoi ora!

Ho pubblicato proxyquire che si occuperà di sovrascrivere il requisito globale all'interno del modulo durante il test.

Ciò significa che non è necessario apportare modifiche al codice per iniettare mock per i moduli richiesti.

Proxyquire ha un'API molto semplice che consente di risolvere il modulo che si sta tentando di testare e di passare lungo mock / stub per i moduli richiesti in un semplice passaggio.

@Raynos ha ragione nel fatto che tradizionalmente dovevi ricorrere a soluzioni non molto ideali per raggiungere questo obiettivo o fare uno sviluppo dal basso

Questo è il motivo principale per cui ho creato proxyquire: per consentire lo sviluppo guidato da test top-down senza problemi.

Dai un'occhiata alla documentazione e agli esempi per valutare se si adatta alle tue esigenze.

Un'opzione migliore in questo caso è quella di deridere i metodi del modulo che viene restituito.

Nel bene o nel male, la maggior parte dei moduli node.js sono singoli; due pezzi di codice che richiedono () lo stesso modulo ottengono lo stesso riferimento a quel modulo.

Puoi sfruttare questo e usare qualcosa come Sinon per deridere gli oggetti che sono richiesti. segue il test moka :

// 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 ha una buona integrazione con Chai per fare affermazioni, e ho scritto un modulo per integrare sinon con moka per consentire una più facile pulizia spia / stub (per evitare il test dell'inquinamento).

Nota che UnderTest non può essere deriso allo stesso modo, poiché UnderTest restituisce solo una funzione.

Un'altra opzione è usare le beffe di Jest. Segui sulla loro pagina

Uso il finto requisito . Assicurati di definire i tuoi mock prima di te requireil modulo da testare.

beffardo require mi sembra un brutto scherzo. Personalmente proverei ad evitarlo e refactoring il codice per renderlo più testabile. Esistono vari approcci per gestire le dipendenze.

1) passare dipendenze come argomenti

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

Ciò renderà il codice universalmente testabile. Il rovescio della medaglia è che è necessario passare dipendenze, il che può rendere il codice più complicato.

2) implementare il modulo come classe, quindi utilizzare metodi / proprietà della classe per ottenere dipendenze

(Questo è un esempio inventato, in cui l'uso della classe non è ragionevole, ma trasmette l'idea) (esempio ES6)

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

class underTestClass {
    getInnerLib () {
        return innerLib
    }

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

Ora puoi facilmente bloccare il getInnerLibmetodo per testare il tuo codice. Il codice diventa più dettagliato, ma anche più facile da testare.

Se hai mai usato jest, allora probabilmente hai familiarità con la funzionalità di jest.

Usando "jest.mock (...)" puoi semplicemente specificare la stringa che si verificherebbe da qualche parte in un'istruzione request nel tuo codice e ogni volta che un modulo è richiesto usando quella stringa verrebbe invece restituito un oggetto simulato.

Per esempio

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

sostituirà completamente tutte le importazioni / i requisiti di "firebase-admin" con l'oggetto restituito da quella funzione "factory".

Bene, puoi farlo quando usi jest perché jest crea un runtime attorno a ogni modulo che esegue e inietta una versione "hooked" di request nel modulo, ma non saresti in grado di farlo senza jest.

Ho cercato di raggiungere questo obiettivo con finto requisito, ma per me non ha funzionato per i livelli nidificati nella mia fonte. Dai un'occhiata al seguente numero su github: mock-request non sempre chiamato con Mocha .

Per risolvere questo problema, ho creato due moduli npm che è possibile utilizzare per ottenere ciò che si desidera.

Hai bisogno di un plug-in per babele e un mocker di moduli.

• babel-plugin-mock-richiedere
• jestlike-finto

Nel tuo .babelrc usa il plug-in babel-plugin-mock-require con le seguenti opzioni:

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

e nel tuo file di test usa il modulo jestlike-mock in questo modo:

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

Il jestlike-mock modulo è ancora molto rudimentale e non ha molta documentazione ma non c'è neanche molto codice. Apprezzo qualsiasi PR per un set di funzionalità più completo. L'obiettivo sarebbe quello di ricreare l'intera funzione "jest.mock".

Per vedere come jest implementa la possibilità di cercare il codice nel pacchetto "jest-runtime". Vedi https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js#L734 per esempio, qui generano un "automock" di un modulo.

Spero che aiuti ;)

Non puoi. È necessario creare la suite di test delle unità in modo che i moduli più bassi vengano testati per primi e che i moduli di livello superiore che richiedono moduli vengano successivamente testati.

Devi anche supporre che qualsiasi codice di terze parti e node.js stesso siano ben testati.

Presumo che nel prossimo futuro arriveranno quadri beffardi che sovrascrivono global.require

Se devi davvero iniettare una simulazione, puoi modificare il codice per esporre l'ambito modulare.

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

Tieni presente che ciò si espone .__modulenella tua API e qualsiasi codice può accedere all'ambito modulare a proprio rischio.

È possibile utilizzare la libreria di derisione :

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'

Codice semplice per deridere i moduli per i curiosi

Nota le parti in cui manipoli il metodo require.cachee note in require.resolvequanto questa è la salsa segreta.

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

Usa come :

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

MA ... proxyquire è davvero fantastico e dovresti usarlo. Mantiene le tue sostituzioni localizzate solo ai test e lo consiglio vivamente.