Ho i seguenti moduli ES6:

network.js

export function getDataFromServer() {
  return ...
}

widget.js

import { getDataFromServer } from 'network.js';

export class Widget() {
  constructor() {
    getDataFromServer("dataForWidget")
    .then(data => this.render(data));
  }

  render() {
    ...
  }
}

Sto cercando un modo per testare Widget con una finta istanza di getDataFromServer. Se avessi usato <script>moduli separati anziché ES6, come in Karma, avrei potuto scrivere il mio test come:

describe("widget", function() {
  it("should do stuff", function() {
    let getDataFromServer = spyOn(window, "getDataFromServer").andReturn("mockData")
    let widget = new Widget();
    expect(getDataFromServer).toHaveBeenCalledWith("dataForWidget");
    expect(otherStuff).toHaveHappened();
  });
});

Tuttavia, se sto testando i moduli ES6 singolarmente al di fuori di un browser (come con Mocha + babel), scriverei qualcosa del tipo:

import { Widget } from 'widget.js';

describe("widget", function() {
  it("should do stuff", function() {
    let getDataFromServer = spyOn(?????) // How to mock?
    .andReturn("mockData")
    let widget = new Widget();
    expect(getDataFromServer).toHaveBeenCalledWith("dataForWidget");
    expect(otherStuff).toHaveHappened();
  });
});

Va bene, ma ora getDataFromServernon è disponibile in window(beh, non c'è windowaffatto), e non conosco un modo per iniettare cose direttamente nel widget.jsproprio ambito.

Quindi dove vado da qui?

1. Esiste un modo per accedere all'ambito widget.jso almeno sostituire le sue importazioni con il mio codice?
2. In caso contrario, come posso renderlo Widgettestabile?

Roba che ho considerato:

un. Iniezione manuale delle dipendenze.

Rimuovere tutte le importazioni da widget.jse aspettarsi che il chiamante fornisca i deps.

export class Widget() {
  constructor(deps) {
    deps.getDataFromServer("dataForWidget")
    .then(data => this.render(data));
  }
}

Sono molto a disagio nel rovinare l'interfaccia pubblica di Widget in questo modo e nel mostrare i dettagli dell'implementazione. Non andare.

b. Esporre le importazioni per consentire di deriderle.

Qualcosa di simile a:

import { getDataFromServer } from 'network.js';

export let deps = {
  getDataFromServer
};

export class Widget() {
  constructor() {
    deps.getDataFromServer("dataForWidget")
    .then(data => this.render(data));
  }
}

poi:

import { Widget, deps } from 'widget.js';

describe("widget", function() {
  it("should do stuff", function() {
    let getDataFromServer = spyOn(deps.getDataFromServer)  // !
      .andReturn("mockData");
    let widget = new Widget();
    expect(getDataFromServer).toHaveBeenCalledWith("dataForWidget");
    expect(otherStuff).toHaveHappened();
  });
});

Questo è meno invasivo ma mi richiede di scrivere un sacco di boilerplate per ogni modulo, e c'è comunque il rischio che io lo usi getDataFromServerinvece di deps.getDataFromServertutto il tempo. Non sono a mio agio, ma finora è la mia migliore idea.

Ho iniziato a utilizzare lo import * as objstile nei miei test, che importa tutte le esportazioni da un modulo come proprietà di un oggetto che può quindi essere deriso. Trovo che sia molto più pulito rispetto all'utilizzo di qualcosa come rewire o proxyquire o qualsiasi tecnica simile. L'ho fatto più spesso quando ho bisogno di deridere azioni Redux, per esempio. Ecco cosa potrei usare per il tuo esempio sopra:

import * as network from 'network.js';

describe("widget", function() {
  it("should do stuff", function() {
    let getDataFromServer = spyOn(network, "getDataFromServer").andReturn("mockData")
    let widget = new Widget();
    expect(getDataFromServer).toHaveBeenCalledWith("dataForWidget");
    expect(otherStuff).toHaveHappened();
  });
});

Se la tua funzione risulta essere un'esportazione predefinita, allora import * as network from './network'produrrebbe {default: getDataFromServer}e puoi deridere network.default.

@carpeliam è corretto ma si noti che se si desidera spiare una funzione in un modulo e utilizzare un'altra funzione in quel modulo che chiama quella funzione, è necessario chiamare quella funzione come parte dello spazio dei nomi delle esportazioni, altrimenti la spia non verrà utilizzata.

Esempio sbagliato:

// mymodule.js

export function myfunc2() {return 2;}
export function myfunc1() {return myfunc2();}

// tests.js
import * as mymodule

describe('tests', () => {
    beforeEach(() => {
        spyOn(mymodule, 'myfunc2').and.returnValue = 3;
    });

    it('calls myfunc2', () => {
        let out = mymodule.myfunc1();
        // out will still be 2
    });
});

Giusto esempio:

export function myfunc2() {return 2;}
export function myfunc1() {return exports.myfunc2();}

// tests.js
import * as mymodule

describe('tests', () => {
    beforeEach(() => {
        spyOn(mymodule, 'myfunc2').and.returnValue = 3;
    });

    it('calls myfunc2', () => {
        let out = mymodule.myfunc1();
        // out will be 3 which is what you expect
    });
});

Ho implementato una libreria che tenta di risolvere il problema del derisione in fase di esecuzione delle importazioni della classe Typescript senza che la classe originale sia a conoscenza di alcuna iniezione di dipendenza esplicita.

La libreria utilizza la import * assintassi e quindi sostituisce l'oggetto esportato originale con una classe stub. Conserva la sicurezza del tipo in modo che i test si interrompano al momento della compilazione se un nome di metodo è stato aggiornato senza aggiornare il test corrispondente.

Questa libreria può essere trovata qui: ts-mock-imports .

La risposta di @ vdloo mi ha portato nella giusta direzione, ma l'uso sia delle parole chiave "export" del commonjs che del modulo ES6 "export" insieme nello stesso file non ha funzionato per me (webpack v2 o successive lamentele). Invece, sto usando un'esportazione predefinita (variabile denominata) che avvolge tutte le singole esportazioni del modulo denominato e quindi importa l'esportazione predefinita nel mio file di test. Sto usando la seguente configurazione di esportazione con mocha / sinon e lo stub funziona bene senza bisogno di ricablare, ecc .:

// MyModule.js
let MyModule;

export function myfunc2() { return 2; }
export function myfunc1() { return MyModule.myfunc2(); }

export default MyModule = {
  myfunc1,
  myfunc2
}

// tests.js
import MyModule from './MyModule'

describe('MyModule', () => {
  const sandbox = sinon.sandbox.create();
  beforeEach(() => {
    sandbox.stub(MyModule, 'myfunc2').returns(4);
  });
  afterEach(() => {
    sandbox.restore();
  });
  it('myfunc1 is a proxy for myfunc2', () => {
    expect(MyModule.myfunc1()).to.eql(4);
  });
});

Ho trovato che questa sintassi funziona:

Il mio modulo:

// mymod.js
import shortid from 'shortid';

const myfunc = () => shortid();
export default myfunc;

Il codice di prova del mio modulo:

// mymod.test.js
import myfunc from './mymod';
import shortid from 'shortid';

jest.mock('shortid');

describe('mocks shortid', () => {
  it('works', () => {
    shortid.mockImplementation(() => 1);
    expect(myfunc()).toEqual(1);
  });
});

Vedere il doc .

Non l'ho provato da solo, ma penso che la beffa potrebbe funzionare. Ti permette di sostituire il modulo reale con un finto che hai fornito. Di seguito è riportato un esempio per darti un'idea di come funziona:

mockery.enable();
var networkMock = {
    getDataFromServer: function () { /* your mock code */ }
};
mockery.registerMock('network.js', networkMock);

import { Widget } from 'widget.js';
// This widget will have imported the `networkMock` instead of the real 'network.js'

mockery.deregisterMock('network.js');
mockery.disable();

Sembra che mockerynon sia più gestito e penso che funzioni solo con Node.js, ma comunque è una soluzione pulita per i moduli beffardi che altrimenti sarebbero difficili da deridere.