Mam następujące moduły 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() {
    ...
  }
}

Szukam sposobu na przetestowanie Widget za pomocą próbnej instancji getDataFromServer. Gdybym użył oddzielnych <script>modułów zamiast modułów ES6, jak w Karmie, mógłbym napisać swój test tak:

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

Jeśli jednak testuję moduły ES6 indywidualnie poza przeglądarką (jak z Mocha + babel), napisałbym coś takiego:

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

OK, ale teraz getDataFromServernie jest dostępny w window(cóż, w ogóle nie ma window) i nie znam sposobu, aby wstrzyknąć rzeczy bezpośrednio do widget.jswłasnego zakresu.

Więc dokąd mam się udać?

1. Czy istnieje sposób uzyskania dostępu do zakresu widget.jslub przynajmniej zastąpienia jego importu własnym kodem?
2. Jeśli nie, w jaki sposób mogę uczynić Widgetmożliwym do przetestowania?

Rzeczy, które rozważałem:

za. Ręczne wstrzykiwanie zależności.

Usuń wszystkie importy z widget.jsi oczekuj, że wywołujący dostarczy deps.

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

Nie podoba mi się zepsucie publicznego interfejsu Widgeta w ten sposób i ujawnianie szczegółów implementacji. Nie idź.

b. Ujawnij importy, aby umożliwić ich kpienie.

Coś jak:

import { getDataFromServer } from 'network.js';

export let deps = {
  getDataFromServer
};

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

następnie:

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

Jest to mniej inwazyjne, ale wymaga ode mnie napisania wielu schematów dla każdego modułu i nadal istnieje ryzyko, że będę go używać getDataFromServerzamiast tego przez deps.getDataFromServercały czas. Niepokoi mnie to, ale jak dotąd to mój najlepszy pomysł.

Zacząłem stosować import * as objstyl w moich testach, który importuje wszystkie eksporty z modułu jako właściwości obiektu, z którego można następnie mockować. Uważam, że jest to o wiele czystsze niż użycie czegoś takiego jak rewire lub proxyquire lub inna podobna technika. Robiłem to najczęściej, gdy potrzebowałem na przykład kpić z akcji Redux. Oto, czego mógłbym użyć w powyższym przykładzie:

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

Jeśli twoja funkcja jest domyślnym eksportem, to import * as network from './network'utworzy {default: getDataFromServer}i możesz mockować network.default.

@carpeliam jest poprawne, ale pamiętaj, że jeśli chcesz szpiegować funkcję w module i użyć innej funkcji w tym module wywołującej tę funkcję, musisz wywołać tę funkcję jako część przestrzeni nazw eksportu, w przeciwnym razie szpieg nie będzie używany.

Błędny przykład:

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

Właściwy przykład:

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

Zaimplementowałem bibliotekę, która próbuje rozwiązać problem mockowania w czasie wykonywania importu klas Typescript bez potrzeby, aby oryginalna klasa wiedziała o jakimkolwiek jawnym wstrzyknięciu zależności.

Biblioteka używa import * asskładni, a następnie zastępuje oryginalny wyeksportowany obiekt klasą pośredniczącą. Zachowuje bezpieczeństwo typów, więc testy zostaną przerwane w czasie kompilacji, jeśli nazwa metody została zaktualizowana bez aktualizacji odpowiedniego testu.

Tę bibliotekę można znaleźć tutaj: ts-mock-Import .

Odpowiedź @ vdloo sprawiła, że ​​poszedłem we właściwym kierunku, ale używanie razem słów kluczowych commonjs „export” i „export” modułu ES6 w tym samym pliku nie zadziałało (narzeka webpack v2 lub nowszy). Zamiast tego używam domyślnego (nazwanej zmiennej) eksportu opakowującego wszystkie poszczególne eksporty z nazwanego modułu, a następnie importuję domyślny eksport w moim pliku testów. Używam następującej konfiguracji eksportu z mokką / sinonem, a stubbing działa dobrze bez konieczności ponownego okablowania itp .:

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

Zauważyłem, że ta składnia działa:

Mój moduł:

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

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

Kod testowy mojego modułu:

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

Zobacz doc .

Sam tego nie próbowałem, ale myślę, że kpina może działać. Pozwala na zastąpienie prawdziwego modułu dostarczonym przez Ciebie makietą. Poniżej znajduje się przykład, który daje wyobrażenie o tym, jak to działa:

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

Wygląda na mockeryto, że nie jest już obsługiwany i myślę, że działa tylko z Node.js, ale nie mniej jednak jest to zgrabne rozwiązanie do wyszydzania modułów, które inaczej są trudne do podrobienia.