Sinon: ネイティブES6Promiseを解決しても、偽のタイマーを使用したときにコールバックがトリガーされない

私もこの問題に遭遇しました

Promiseの仕様ではsetTimeoutを使用していないため、これを解決できるとは思いませんが、現在のジョブの直後に新しいジョブを実行するようにスケジュールします。

テストから約束を返してみましたか？ 現在、ほとんどのテストライブラリはpromiseをサポートしており、 it()関数がpromiseを返す場合、テストランナーはpromiseが解決または拒否されるのを待ってから、テストが完了したことを通知します。

はい、テストから約束を返すことはおそらくうまくいきます。 しかし、偽のタイマーを使用する場合、テスト機能から戻る前にテストに参加できると期待しています。 それは一種の要点です。

これは、Dateオブジェクトが置き換えられるのと同じように、Promiseオブジェクトを置き換えることで実行できると確信しています。 それを可能にするには、ネイティブ実装に依存することができないため、promise仕様の競合する実装が必要になる可能性があります。

皆さんがここで指摘している問題がわかります。 私が遭遇した特定の状況を指摘したかったのですが、promiseの仕様とsinonのドキュメントの両方に基づいて、これは「機能するはず」であるように見えました。 この場合、私は約束をテストに戻していますが、偽のタイマーを使用すると、約束が解決されないように見えます。

これらのテストは両方とも機能するはずですが、最初のテストは成功し、2番目のテストは失敗します。 mochaでchai-as-promisedプラグインでchaiを使用していますが、「2000msのタイムアウトを超えました。このテストでdone（）コールバックが呼び出されていることを確認してください。」というエラーが表示されます。

describe('chai as promised', function() {

    it('should resolve a promise', function() {
        var promise = new Promise(function( resolve ) {
            setTimeout( resolve, 1000 );
        });
        return expect( promise ).to.have.been.fulfilled;
    });

});

describe('sinon.useFakeTimers()', function() {

    before(function() {
        this.clock = sinon.useFakeTimers();
    });

    after(function() {
        this.clock.restore();
    });

    it('should resolve a promise after ticking', function() {

        var promise = new Promise(function( resolve ) {
            setTimeout( resolve, 1000 );
        });

        this.clock.tick( 1001 );

        return expect( promise ).to.have.been.fulfilled;
    });

});

簡単なテストプロジェクトをまとめました： https ：//github.com/JustinLivi/sinon-promises-test

テストが完了する前に復元することは、実行可能な回避策のようです。

describe('sinon.useFakeTimers()', function() {

    before(function() {
        this.clock = sinon.useFakeTimers();
    });

    it('should resolve a promise after ticking', function() {

        var promise = new Promise(function( resolve ) {
            setTimeout( resolve, 1000 );
        });

        this.clock.tick( 1001 );
        this.clock.restore();

        return expect( promise ).to.have.been.fulfilled;
    });

});

私たちが使用している回避策は、テストを実行するときに、ネイティブのpromise実装をsetTimeoutに依存する単純なものに置き換えることです。

window.Promise = require('promise-polyfill')

Sinon.JSは、useFakeTimersを呼び出すときに同じことを簡単に行うことができます。

@JustinLiviは、完了する前に復元してくれました：+1：

それで、解決策や回避策はありますか？
私のテストではそう言われているので、アプリを変更してES6Promisesの使用を停止することはできません:)

ネイティブプロミスではなく、es6-promiseポリフィルに問題があります。
@JustinLiviのclock.restore()ソリューションで問題が修正されます。

この問題が長い間ここに残っている理由はわかりませんが、これはSinonの問題ではありません。 Promisesを使用すると、基本的に非同期ロジックが実行されます。 それでも、ここでのすべてのテストは同期ロジックを使用しています（OPが実際に言及しているように）。 そのため、時間を偽造していても、関数の終了後にPromiseを使用して実行することになります。つまり、テストを少し変更する必要があります。 これは通常、ほとんどのテストフレームワーク（これはMochaからのものです）のドキュメントでカバーされていますが、今後の新しいサイトでテストレシピを取り上げたいくつかの記事でこれに対処します。

したがって、 @ JustinLiviの例を少し変更すると、次のテストが行​​われます。

var sinon = require('sinon');

describe('sinon.useFakeTimers()', function() {

    before(function() {
        this.clock = sinon.useFakeTimers();
    });

    it('should resolve a promise after ticking', function(done) {

        var promise = new Promise(function( resolve ) {
            setTimeout( resolve, 10000 );
        });

        this.clock.tick( 10001 );

        promise
            .then(done) // call done when the promise completes
            .catch(done); // catch any accidental errors
    });

});

実際、Mochaを使用している場合、Promiseをテストフレームワークに直接返すだけで、Promisesを使用するときに上記と同じコードの「ショートカット」バージョンがあります。

it('should resolve a promise after ticking', function() {
    var promise = new Promise(function( resolve ) {
        setTimeout( resolve, 10000 );
    });

    this.clock.tick( 10001 );

    return promise;
});

この意志

1. Promiseコンストラクターにパラメーターとして送信されたexecutor関数を同期的に実行し（ ES2015仕様を参照）、新しいタイムアウトを効果的に設定します。
2. 構築された約束を返します。
3. 時間を刻みます。
4. タイムアウト関数をトリガーし、promiseを解決済みとしてマークします
5. process （またはブラウザ）は新しい「ティック」をスタックし、約束を解決して残りのThenablesを呼び出します

これをバグではないものとして閉じます。

@ fatso83あなたが説明した方法でテストに合格する方法がわかりません。 サンプルテストをテストリポジトリに追加しましたが、それでもtimeout of 2000ms exceeded. Ensure the done() callback is being called in this test.を取得します

ここを参照してください： https ：//github.com/JustinLivi/sinon-promises-test/blob/master/test.js#L60
また、私が知る限り、このテストはまだ失敗します： https ：//github.com/JustinLivi/Sinon.JS/commit/de106e6db2f5cc076b7e3a78635bd9ae2b6be1c2

編集： @fpirschによるコメントに基づくと、es6 promiseポリフィルを使用しているときだけのようですか？ ブルーバードなどの代替ライブラリを試した人はいますか？

@ fatso83これはreturn promiseの問題ではありません。
私の場合、これはファントム（古い、約束なし）+ es6-promises polyfill + sinon.jsの問題です。 最近のブラウザでは、promiseは解決され、テストは正常に実行されますが、promise polyfillを使用すると、タイマーが偽造されたときにPromiseが解決されることはありません。

@JustinLiviと@fpirsch ：このバグレポートは_native_promiseの使用に関するものでした。 @JustinLiviのテストプロジェクトがes6-promiseを使用しているので、それを保証することはできません。 他のポリフィルについても同じことが言えます。それは別の問題です。 私はこれをノード5と6でテストしました。これらはネイティブのpromiseをサポートしています。

前の投稿からサンプルコードをコピーして貼り付けて実行します（MochaとSinonがプリインストールされています）。

$ pbpaste > test.js

$ mocha test.js

  sinon.useFakeTimers()
    ✓ should resolve a promise after ticking

  1 passing (12ms)

@fpirsch ： return promiseの問題だとは決して言いませんでした。 私は彼がテストをより短い形式で書き直すことができるとちょうど述べました。 修正ではなく、ヒント。 しかし、あなたはいくつかの貴重な情報を提供しました：それはネイティブブラウザで動作しますが、promiseポリフィルでは失敗します。 それはあなたの約束のlibのせいであり、Sinonのせいではありません。 あなたのpromiselibは、おそらくsetTimeoutとその友達をキャッシュせず、関数をそれに依存しているため、壊れています。 pinkyswear libにこれに対する修正を一度実装したので、不思議ではありません。

es6-promiseのソースをチェックしましたが、setTimeoutへの参照をキャッシュしないため、sinonが行うことの影響を受けます。 しかし、私はそのスケジューラーがここでどのように関連しているかを見ることができません...タイムアウトスケジューラーにフォールバックする前にポリフィルが試みる他のオプションの膨大なリストもあります。 そのフォールバックに到達するブラウザはすべて古くなければなりません:)

しかしとにかく、 @ fpirschと@JustinLiviが言及しているのは、Sinonとポリフィルの間の相互運用性に関する問題です。 そしてそれは別の問題です。 SinonがATMについてどのようにできるかはわかりませんが（PRはes6-polyfillになる可能性が高くなります）、これがSinonの問題である場合は、新しい問題を開いてください。

PS @ropezからのヒントは、 promise-polyfillを使用することだったと思います。これは、最小限のポリフィルについても実際に推奨されていますが、与えられたものとは逆の理由です。 @mroderickは、1月（ @ropezコメントの数か月後）にそのプロジェクトにパッチを適用して、 setTimeoutへの参照をキャッシュし、約束が_どのようなシノンが行っていても_グローバルsetTimeout参照に解決されるようにしました。 詳細については、taylorhakes / promise-polyfill＃15を参照してください。

@ fatso83情報をありがとう。 残念ながら、 @ mroderickがpromise-polyfillに対して行ったように、 setTimeoutへの参照を保存しても、私の場合は機能しません。 es6-promiseをpromise-polyfillに置き換えることもありません:-(
編集：それは単純なファントム+モカスタックでは機能しますが、カルマを含む完全なスタックでは機能しません。 これにうんざりしている。

@ fatso83ここに例を示します： faketimers
結局のところ、問題はカルマにあるのかもしれません...私はこれをより深く掘り下げようとします。

@fpirsch ：あなたは何かに取り組んでいると思います。 あなたも@JustinLiviも、テストランナーとしてカルマに依存しています。 それらは非常に似ているようです。 PSジャスティンがすでに問題を示したテストケースを提供していたので、コメントは完全に不要だと思ったので削除しましたが、あなたのサンプルプロジェクトは、これがカルマのものであるという仮説を強化します。ありがとう！

これは関連しているかもしれませんが、よくわかりません。 以下の3番目のテストが失敗するのはなぜですか？ 特定の失敗は、典型的なテストタイムアウトです。

     Error: timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.

describe.only('working', () => {
  let clock;
  beforeEach(() => { clock = Sinon.useFakeTimers(); })
  afterEach(() => { clock.restore() })

  const delay = (ms) => (
    new Promise((resolve/* , reject */) => {
      setTimeout(resolve, ms)
    })
  );

  it('1 OK', () => {
    const promise = new Promise((resolve) => {
      setTimeout(resolve, 100)
    })
    clock.tick(200)
    return promise
  })

  it('2 OK', () => {
    const promise = delay(100)
    clock.tick(200)
    return promise
  })

  it('3 FAIL', () => {
    const promise = delay(50).then(() => delay(50))
    clock.tick(200)
    return promise
  })
})

@jasonkuhrt clock.tickがエグゼキュータを同期的に処理し、非同期の性質のために.then(...)が実行されないため、3番目のテストは失敗します。

onFulfilledまたはonRejectedは、実行コンテキストスタックにプラットフォームコードのみが含まれるまで呼び出さないでください。

@ fatso83タイマーを追加する連鎖プロミスに関するlolex開発者の立場がわかりません。 現在の制限については、少なくともドキュメントで詳しく説明する必要があります。

これをサポートする必要があるかどうかに応じて、この問題を再度開くことができ（または新しい問題を開くことができます）、 lolexの新しい問題に依存します。
また、このユースケース（タイマーを追加するチェーンの約束）を考慮に入れる必要がある場合、これは混乱するlolex APIの変更につながると思います（AFAIK clock.tickは非同期である必要があります）。

@gautazああ、今は理にかなっています。 説明してくれてありがとう！

lolexは同期ライブラリであり、 @ jasonkuhrtの問題を解決する方法が完全にはわかりません。 PRを自由に提供してください。ただし、 clock.tickを変更することはあまり魅力的ではありません。 むしろ、追加の非同期メソッドが必要です。

私はプロミスとクロックティックに関して多くの問題を抱えたことはありませんでしたが、それはおそらくそれらが同期していることを確認し、その間に余分なクロックティックを追加したためです。

@ fatso83そうです、非同期のtickを追加すると、混乱が少なくなります（実際にはまったく混乱しません）。
したがって、 asyncTickのようなものが適切かもしれません。 時間があれば調べてみます。

@gautazは、 lolexにパッチを提供することに取り掛かったことがあるかどうかだけ知りたいですか？

@ fatso83こんにちは、私は昨年自分の側で支店を始めましたが、今のところ仕事を終える時間はありません。
同じ問題でつまずいた同僚がいるので、問題が大きくなって追加の時間を提供できることを願っています。

その間に、この特定の点でlolex APIに関して何か変更がありましたか？

あるべきではありません。 過去半年間のコードベースの変更はほとんどありません。 かなり安定しています。

ここで簡単な回避策をとるチャンスはありますか？ 同じ問題があります。 私には2つの約束があり、それらはsetTimeoutによって解決されます。 解決する前、2番目の解決前、最初の解決後、そしてすべての解決後に確認する必要があります。

必要なのは、promiseマイクロタスクが実行されるのを待つことだけです。
したがって、次のアプローチは完璧に機能します。

const tick = async (ms) => {
  clock.tick(ms);
};

it("imitates promise fulfill when called once", async () => {
    new Promise(resolve => setTimeout(resolve, 400)).then(callback);
    expect(callback.callCount).to.eql(0);

    await tick(200);
    expect(callback.callCount).to.eql(0);

    await tick(200);
    expect(callback.callCount).to.eql(1);
  });

@jakwuhのトリックは私のために機能しました（ノード8、トランスパイルなし、ネイティブプロミス）。ただし、 thenコールバックはティックによって延期されました。

更新されたコメント：私の元のコメント（下記）の解決策には問題があります。 実際にすべてをフラッシュするために、複数の連続しawait Promise.resolve()呼び出しが必要になることがありました。 これがもう少しうまくいくように見えるものです：

beforeEach(function() {
    const originalSetImmediate = setImmediate;
    this.clock = sinon.useFakeTimers();
    this.tickAsync = async ms => {
        this.clock.tick(ms);
        await new Promise(resolve => originalSetImmediate(resolve));
    }
});

afterEach(function() {
    this.clock.restore();
});

元のコメント[警告：上記のコードと同様に機能しません。]

tickヘルパーに非同期ギャップを追加すると、問題が修正されました。

`` `js
const tick = async（ms）=> {
clock.tick（ms）;
Promise.resolve（）;を待つ
};

この分野でSinonを改善する作業（実際には、その兄弟プロジェクトlolex ）に関心のある人は、ここでのディスカッションを確認してください。

• https://github.com/sinonjs/lolex/issues/114
• https://github.com/sinonjs/lolex/pull/105