Comment stub un Tapuscrit-Interface / Type de définition?

J'ai écrit Tapuscrit tests à l'aide de qUnit et Sinon, et j'ai vécu exactement la même douleur que vous décrivez.

Supposons que vous avez une dépendance sur une interface comme:

interface IDependency {
    a(): void;
    b(): boolean;
}

J'ai réussi à éviter la nécessité de nouveaux outils/bibliothèques en utilisant un couple d'approches fondées sur sinon stubs/espions et de moulage.

• Utiliser un objet vide littéral, alors affecter directement sinon talons pour les fonctions utilisées dans le code:

  //Create empty literal as your IDependency (usually in the common "setup" method of the test file)
  let anotherDependencyStub = <IDependency>{};
  
  //Set stubs for every method used in your code 
  anotherDependencyStub.a = sandbox.stub(); //If not used, you won't need to define it here
  anotherDependencyStub.b = sandbox.stub().returns(true); //Specific behavior for the test
  
  //Exercise code and verify expectations
  dependencyStub.a();
  ok(anotherDependencyStub.b());
  sinon.assert.calledOnce(<SinonStub>anotherDependencyStub.b);

• Usage littéral d'objet avec vide implémentations des méthodes nécessaires à votre code, puis les envelopper méthodes sinon espions/talons comme l'exige

  //Create dummy interface implementation with only the methods used in your code (usually in the common "setup" method of the test file)
  let dependencyStub = <IDependency>{
      a: () => { }, //If not used, you won't need to define it here
      b: () => { return false; }
  };
  
  //Set spies/stubs
  let bStub = sandbox.stub(dependencyStub, "b").returns(true);
  
  //Exercise code and verify expectations
  dependencyStub.a();
  ok(dependencyStub.b());
  sinon.assert.calledOnce(bStub);

Ils travaillent très agréable lorsque vous les combinez avec sinon les bacs à sable et les communes de l'installation/démontage comme celui fourni par qUnit modules.

• Dans la commune de configuration, vous créez un nouveau bac à sable et à l'objet fantaisie littéraux pour vos dépendances.
• Dans le test que vous venez de spécifier les espions/stubs.

Quelque chose comme ceci (à l'aide de la première option, mais fonctionne de la même façon que si vous utilisiez la deuxième option):

QUnit["module"]("fooModule", {
    setup: () => {
        sandbox = sinon.sandbox.create();
        dependencyMock = <IDependency>{};
    },
    teardown: () => {
        sandbox.restore();
    }
});

test("My foo test", () => {
    dependencyMock.b = sandbox.stub().returns(true);

    var myCodeUnderTest = new Bar(dependencyMock);
    var result = myCodeUnderTest.doSomething();

    equal(result, 42, "Bar.doSomething returns 42 when IDependency.b returns true");
});

Je suis d'accord ce n'est pas encore la solution idéale, mais il fonctionne raisonnablement bien, n'a pas besoin de bibliothèques supplémentaires et conserve la quantité de code nécessaire à un faible niveau gérable.

OriginalL'auteur Daniel J.G.

Il y a quelques bibliothèques qui permet de faire TypeMoq, TeddyMocks et Typescript-mockify sont probablement l'un des plus populaires.

Vérifier le github de référentiels et de choisir celui que vous aimez mieux :
liens:

• TeddyMocks: https://github.com/mbraude/TeddyMocks
• TypeMoq: https://github.com/florinn/typemoq
• TypeScriptMockify: https://github.com/brechtbilliet/typescript-mockify

Vous pouvez également utiliser de plus en plus populaire libs comme Sinon, mais d'abord vous devez utiliser un <any> type puis le réduire à <IDependency> type (Comment puis-je utiliser Sinon avec Tapuscrit?)

OriginalL'auteur PolishDeveloper

Vous pouvez essayer moq.ts, mais il dépend de l'objet Proxy

interface IDependency {
  a(): number;
  b(): string;
}


import {Mock, It, Times} from 'moq.ts';

const mock = new Mock<IDependency>()
  .setup(instance => instance.a())
  .returns(1);

mock.object().a(); //returns 1

mock.verify(instance => instance.a());//pass
mock.verify(instance => instance.b());//fail

OriginalL'auteur dvabuzyarov