J'ai les modules ES6 suivants:

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() {
    ...
  }
}

Je cherche un moyen de tester Widget avec une instance simulée de getDataFromServer. Si j'utilisais des <script>s séparés au lieu de modules ES6, comme dans Karma, je pourrais écrire mon test comme:

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

Cependant, si je teste les modules ES6 individuellement en dehors d'un navigateur (comme avec Mocha + babel), j'écrirais quelque chose comme:

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

D'accord, mais maintenant getDataFromServern'est pas disponible dans window(enfin, il n'y en a pas windowdu tout), et je ne connais pas un moyen d'injecter des trucs directement dans son widget.jspropre scope.

Alors, où dois-je partir d'ici?

1. Existe-t-il un moyen d'accéder à la portée de widget.js, ou au moins de remplacer ses importations par mon propre code?
2. Sinon, comment puis-je rendre Widgettestable?

Les choses que j'ai envisagées:

une. Injection manuelle de dépendances.

Supprimez toutes les importations widget.jset attendez de l'appelant qu'il fournisse les deps.

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

Je suis très mal à l'aise de gâcher l'interface publique de Widget comme celle-ci et d'exposer les détails de mise en œuvre. Ne pas aller.

b. Exposez les importations pour permettre de les moquer.

Quelque chose comme:

import { getDataFromServer } from 'network.js';

export let deps = {
  getDataFromServer
};

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

puis:

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

Ceci est moins invasif mais m'oblige à écrire beaucoup de passe-partout pour chaque module, et il y a toujours un risque que j'utilise getDataFromServerau lieu de deps.getDataFromServertout le temps. Je suis inquiet à ce sujet, mais c'est ma meilleure idée jusqu'à présent.

J'ai commencé à utiliser le import * as objstyle dans mes tests, qui importe toutes les exportations d'un module en tant que propriétés d'un objet qui peuvent ensuite être simulées. Je trouve que c'est beaucoup plus propre que d'utiliser quelque chose comme rewire ou proxyquire ou toute autre technique similaire. Je l'ai fait le plus souvent lorsque j'ai besoin de simuler des actions Redux, par exemple. Voici ce que je pourrais utiliser pour votre exemple ci-dessus:

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

Si votre fonction se trouve être une exportation par défaut, alors import * as network from './network'produirait {default: getDataFromServer}et vous pouvez vous moquer de network.default.

@carpeliam est correct mais notez que si vous voulez espionner une fonction dans un module et utiliser une autre fonction dans ce module appelant cette fonction, vous devez appeler cette fonction dans le cadre de l'espace de noms des exportations, sinon l'espion ne sera pas utilisé.

Mauvais exemple:

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

Bon exemple:

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

J'ai implémenté une bibliothèque qui tente de résoudre le problème de la simulation au moment de l'exécution des importations de classes Typescript sans avoir besoin de la classe d'origine pour connaître toute injection de dépendance explicite.

La bibliothèque utilise la import * assyntaxe, puis remplace l'objet exporté d'origine par une classe stub. Il conserve la sécurité de type afin que vos tests soient interrompus lors de la compilation si un nom de méthode a été mis à jour sans mettre à jour le test correspondant.

Cette bibliothèque se trouve ici: ts-mock-importations .

La réponse de @ vdloo m'a poussé dans la bonne direction, mais l'utilisation des mots-clés commonjs "exports" et du module ES6 "export" ensemble dans le même fichier ne fonctionnait pas pour moi (webpack v2 ou ultérieur se plaint). Au lieu de cela, j'utilise une exportation par défaut (variable nommée) enveloppant toutes les exportations de modules nommés individuels, puis j'importe l'exportation par défaut dans mon fichier de tests. J'utilise la configuration d'exportation suivante avec mocha / sinon et le stubbing fonctionne bien sans avoir besoin de recâblage, etc.:

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

J'ai trouvé que cette syntaxe fonctionnait:

Mon module:

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

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

Code de test de mon module:

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

Voir la doc .

Je ne l'ai pas essayé moi-même, mais je pense que la moquerie pourrait fonctionner. Il vous permet de remplacer le module réel par une maquette que vous avez fournie. Voici un exemple pour vous donner une idée de son fonctionnement:

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

Il semble que ce mockeryn'est plus maintenu et je pense que cela ne fonctionne qu'avec Node.js, mais néanmoins, c'est une solution intéressante pour se moquer des modules qui sont autrement difficiles à se moquer.