Jest: Promise解決キューをフラッシュするためのAPIを提供します

非同期テストでは、テスト関数をPromiseとして返すことができることを覚えておくとよいでしょう。そのため、次のように機能します。

test('my promise test', () => { //a test function returning a Promise
  return Promise.resolve(load.succeed(result))
    .then(() => {})
    .then(() => expect(result).toHaveBeenCalledWith(result));
})

テスト関数からPromiseを返すと、Jestはこれが非同期テストであることを認識し、解決されるかタイムアウトするまで待機します。

@thymikeeもちろん、私はJestを待たせるために値を返しています-それは完全にポイントから外れています。 コードに.then(() => {})という行を残したことに注意してください。 冒頭の投稿ですでに説明したよりも、問題をより簡潔に説明する方法がわかりません。 それをよく読んで、問題を再開するか、回避方法を説明してください。

_混乱を避けるために、OPのコードにreturnを追加しました。_

同様の問題が発生し、ここで説明しました： https ：

つまり、ユーザーインタラクション（酵素を使用してシミュレート）の結果としてReduxストアにディスパッチされた一連のアクションを表明しようとしています。 Promisesを使用してディスパッチされた同期および非同期としてのアクション（すぐに解決するためにモックされます）。 プロミスチェーンに直接アクセスできない場合、プロミスチェーンが使い果たされた後に主張する方法はないようです。 setTimeout(..., 0)機能しますが、ハッキーな感じがします。 setTimeoutのコールバックでアサーションが失敗すると、Jestは（アサーションエラーではなく）タイムアウトエラーで失敗します。

flushAllPromisesのアイデアは解決策のように思えますが、それがrunAllTicksすべきことだと思いますか？

フォローアップとして： setTimeout(..., 0)をsetImmediate置き換えようとしましたが、これはPromiseコールバックマイクロタスクキューが使い果たされた後にアサーションを実行し、Jestがアサーションエラーでタイムアウトするのを防ぐようです。 したがって、これは問題なく機能し、私のユースケースでは許容できるソリューションです。

test('changing the reddit downloads posts', done => {
    setImmediate(() => {
        // assertions...
        done()
    })
})

ヘルパー関数はそれ自体をpromiseに変えることができるので、完了したコールバックを処理する必要はありません。 それは十分に小さいので、ユーザーランドに置いておくのはかなり無害ですが、それがjestオブジェクトに配置されていても文句はありません。 このようなものは私のプロジェクトでよく使われます。

function flushPromises() {
  return new Promise(resolve => setImmediate(resolve));
}

test('', () => {
  somethingThatKicksOffPromiseChain();
  return flushPromises().then(() => {
    expect(...
  });
})

async awaitを使用すると、ほとんどきれいになります。

test('', async () => {
  somethingThatKicksOffPromiseChain();
  await flushPromises();
  expect(...
})

@jwbayそれはすぐそこにある素敵な砂糖です🍠！

このflushPromisesがワンライナーであることが判明したのは事実ですが、その1行に到達する方法はまったく明らかではありません。 したがって、Jestユーザーがutil関数として使用できるようにするとメリットがあると思います。

@pekalaワンライナーIMOは、次の保留中の約束が解決されるまで待機しないため、必要な動作を提供しません。

function foo() {  
  return new Promise((res) => {
    setTimeout(() => {
      res()
    }, 2000);
  });
}

Promiseをスウィズリングするのはどうですか？新しいPromiseが作成されたら、それをいくつかの配列に追加してから、この配列全体でPromise.allで待機するすべてのPromiseをフラッシュしますか？

@talkolあなたが偽のタイマーも私たちに提供している限り、そうなると思います。 私はそれをテストしていません。

@pekalaは、時間に達した後にのみpromiseが解決されるため、この例でタイマーを偽造する必要はありません。
渦巻くプロミスが冗談の内部の仕組みを台無しにするのではないかと心配しています、それは少しハードコアです

偽のタイマーを使用しない場合、テストは実際に2秒以上かかります。 ベストプラクティスは、これらのタイプの遅延を削除することだと思います。その場合、 @ jwbayによって提案されたflushPromisesがその役割を果たします。

すべてはあなたがテストしようとしているものに依存します:)私が言っているのはタイマーが約束を待つこととは無関係の懸念であるということだけです

setTimeout呼び出しと混ざり合っている、Promisesが解決されないことに関連する問題が発生しています。 jest v19.0.2では問題はありませんが、jest v20.0.0では、Promiseが解決/拒否関数に入ることがないため、テストは失敗します。 私たちの問題は、_Promise解決キューをフラッシュするAPIがない_というこの問題に関連しているようですが、この問題は、問題が発生し始めたjest v20.0.0よりも前のものであるように思われるため、完全にはわかりません。

私たちは一連の交互持っているので、これは、我々が来アップすると私たちのテストのいくつかのためにできました唯一のソリューションですsetTimeout Sをし、 Promise sの最終的に呼び出すコードで使用しますonUpdateFailedコールバック。

  ReactTestUtils.Simulate.submit(form);
  return Promise.resolve()
    .then(() => { jest.runOnlyPendingTimers(); })
    .then(() => { jest.runOnlyPendingTimers(); })
    .then(() => { jest.runOnlyPendingTimers(); })
    .then(() => {
      expect(onUpdateFailed).toHaveBeenCalledTimes(1);
      expect(getErrorMessage(page)).toEqual('Input is invalid.');
    });

それほどきれいではないので、ここでのアドバイスは大歓迎です。

テストからpromiseを返すことができない別の例：

describe('stream from promise', () => {
  it('should wait till promise resolves', () => {
    const stream = Observable.fromPromise(Promise.resolve('foo'));
    const results = [];
    stream.subscribe(data => { results.push(data); });
    jest.runAllTimers();
    expect(results).toEqual(['foo']);
  });
});

このテストはjest20.0.4で失敗します。

@philwhlnのソリューションはasync / awaitで書くこともできます

ReactTestUtils.Simulate.submit(form);

await jest.runOnlyPendingTimers();
await jest.runOnlyPendingTimers();
await jest.runOnlyPendingTimers();

expect(onUpdateFailed).toHaveBeenCalledTimes(1);
expect(getErrorMessage(page)).toEqual('Input is invalid.');

promiseキューをフラッシュするユーティリティ関数が欲しい

テスト間でもpromiseキューをフラッシュする関数が欲しいです。

Promise.allを使用して複数のpromiseをラップするコードをテストしています。 これらのラップされたpromiseの1つが失敗すると（それがテストしたいため）、promiseはすぐに返されます。つまり、次のテストの実行中に他のPromise（競合状態、非決定論的）が返されることがあります。

これは、私のテストで予測不可能/反復可能な結果を​​もたらすあらゆる種類の大混乱を引き起こします。

これを適切に実装するには、 Promiseをモックする必要があります。これにより、キューに入れられたすべてのマイクロタスクを最終的に確認して、それらを同期的に解決できます。 promise-mockが行っていることの邪魔になる何か。

process.nextTickキューに入れられたマイクロタスクをフラッシュするAPIがすでにあり、そのAPIはおそらくPromises（ jest.runAllTicks ）でも機能するはずです。

ジャスミンを使って、promiseライブラリであるnextTick of Yakuに接続し、nextTickの呼び出しをキャッチして、それらを早期に再生できるようにするソリューションがありました。
ただし、jestはpromise自体を使用するため、これが問題になります。
結局、私はYakuを取り、それをハッキングして、キューをフラッシュするフラッシュメソッドを作成しました。 デフォルトでは、nextTickを使用して通常どおり実行されますが、flushを呼び出すと、保留中のすべてのPromiseハンドラーが実行されます。
ソースはここにあります：
https://github.com/lukeapage/yaku-mock
それは片付け、ysmoodに連絡して彼らがどう思うかを確認し、ドキュメントを追加することで行うことができますが、テストでpromiseを同期させるための簡単なソリューションとして、あなたが望むことをほぼ実行し、私のために働きました。

それに対する簡単な回避策として、私は@jwbayのソリューションが好きです。

jestオブジェクトに似たものを追加するのはどうですか？

await jest.nextTick();

として実装

const nextTick = () => new Promise(res => process.nextTick(res));

cc @cpojer @SimenB @rogeliog

Reactコンポーネントをマウントするために酵素を使用しています。

私もPromisesの実行を期待する関数を持っていますが、前述の修正はどれも機能しませんでした。 テストでは、関数がawaitを使用してPromiseオブジェクトを返した場合、それらを同期的に処理できますが、残念ながら、関数はPromiseオブジェクトを返しません。

これは、グローバルなPromise関数でスパイを使用することになった回避策です。

global.Promise = require.requireActual('promise');

it('my test', async () => {
    const spy = sinon.spy(global, 'Promise');

    wrapper.props().dispatch(functionWithPromiseCalls());

    for (let i = 0; i < spy.callCount; i += 1) {
      const promise = spy.getCall(i);
      await promise.returnValue;
    }

    expect(...)
});

私はこれのユースケースに遭遇しました（素晴らしいテクニックをありがとう@jwbay ）

たとえば、関数にタイムアウトがあり、タイムアウトが正確に適用されていることを確認するとします。

      jest.useFakeTimers();
      const EXPECTED_DEFAULT_TIMEOUT_MS = 10000;

      const catchHandler = jest.fn().mockImplementationOnce(err => {
        expect(err).not.toBeNull();
        expect(err.message).toContain('timeout');
      });

      // launch the async func returning a promise
      fetchStuffWithTimeout().catch(catchHandler);

      expect(catchHandler).not.toHaveBeenCalled(); // not yet

      jest.advanceTimersByTime(EXPECTED_DEFAULT_TIMEOUT_MS - 1);
      await flushPromises();

      expect(catchHandler).not.toHaveBeenCalled(); // not yet

      jest.advanceTimersByTime(1);
      await flushPromises();

      expect(catchHandler).toHaveBeenCalledTimes(1); // ok, rejected precisely

約束を返すことは、解決/拒否の正確なタイミングをチェックすることを許可しません。

そこでは約束のフラッシングが必要です。 それがなければ、期待は早すぎます。

これが問題の絞り込みに役立つことを願っています。

フォローしている人のために、ここにこれに関するオープンPRがあります：＃6876

https://github.com/airbnb/enzyme/issues/1587からのクロスポスト

この問題を解決するには、次のパターンで十分かどうか、また、悪い習慣と見なされることをしているのに、すべきではないのではないかと思います。

人々はこのアプローチについてどう思いますか？

export class MyComponent extends React.Component {
  constructor (props) {
    super(props)

    this.hasFinishedAsync = new Promise((resolve, reject) => {
      this.finishedAsyncResolve = resolve
    })
  }

  componentDidMount () {
    this.doSomethingAsync()
  }

  async doSomethingAsync () {
    try {
      actuallyDoAsync()
      this.props.callback()
      this.finishedAsyncResolve('success')
    } catch (error) {
      this.props.callback()
      this.finishedAsyncResolve('error')
    }
  }

  // the rest of the component
}

そしてテストでは：

it(`should properly await for async code to finish`, () => {
  const mockCallback = jest.fn()
  const wrapper = shallow(<MyComponent callback={mockCallback}/>)

  expect(mockCallback.mock.calls.length).toBe(0)

  await wrapper.instance().hasFinishedAsync

  expect(mockCallback.mock.calls.length).toBe(1)
})

componentDidMountで非同期呼び出しが直接実行されなかったときに問題が発生しましたが、非同期関数を呼び出していたり​​、別の非同期関数を呼び出していたり​​していました。 すべての非同期チェーンに追加の非同期ステップを追加した場合、追加の.then()または追加のawaitを追加する必要がありますが、これは問題なく機能しています。

私がこのアプローチを使うべきではない理由はありますか、それともこれは人々にとって良さそうですか？

私はユーザーランドでこれを行う冒険に行きましたが、実際には実行可能でそれほど悪くはないことがわかりました（ただし、マップがない場合に遭遇する落とし穴はかなりあります）。 これは、（うまくいけば）直接使用するのに十分詳細なエクスペリエンスレポートです。 TLDRは、 async / awaitをpromiseにトランスパイルし、bluebirdのネイティブpromiseとlolexのネイティブタイマーを交換します。 node_modules/を含むすべてをトランスパイルしqueueMicrotaskはpromiseに必要なプリミティブですが、JSDOMが提供しないため、デフォルトではlolexはそれを提供しません。

私は同じ問題に遭遇したjest.mockAllTimers()呼び出して反応コンポーネントPromiseでcomponentDidMount() 。

＃issuecomment-279171856のソリューションは、エレガントな方法で問題を解決しました。

公式のJestAPIにも同様のものが必要です。

私は最近、たくさんのものをアップグレードしているときに問題に遭遇しました、それは私たちがいつも約束が終わるのを待っていなかったたくさんのテストで問題を明らかにしました。 await new Promise(resolve => setImmediate(resolve));ようなメソッドは単純なケースでは機能しましたが、テストで見つけたので、パイプをクリアするためにそれを数回実行する必要がありました。 これは、 @ quasicomputationalがここでの調査です。 残念ながら、約束が作成されたときにそれを傍受せずに、そのパイプがいつクリアされたかを知る方法はないと思います。 だから私はそれを行うための小さなライブラリを作成しました... promise-spy 。 ただし、偽のタイマーを使用したテストが1つあり、それでは機能しませんでした...そのため、まだ完全に機能するソリューションではありません。

また、それらがpromiseにトランスパイルされている場合、テスト対象のコード内のasync / awaitすべてでのみ機能する可能性があると思います。 それらが約束にトランスパイルされていない場合、このライブラリはそれらにフックして、それらが完了するのを待つことができません。

私はこれと同じ問題を抱えていることに気づき、次のことに気づきました。
保留中のプロミスをフラッシュするのではなく、保留中のプロミスがある場合はテスト全体を失敗させる必要があります。
このようにして、Abort Controllerを使用して、テストされたコード内の保留中のpromiseを強制的に中止します。
https://developers.google.com/web/updates/2017/09/abortable-fetch
冗談を言うことを約束することは、「並行性は難しいので、テストしないでください」と言うことと同じです。 実際には、それはまったく逆のはずです。
並行性は難しいので、さらにテストし、保留中の約束でテストに合格しないようにする必要があります。

このStackoverflowの質問で約束を中止することの混乱を考えると、（まだ）簡単なことではありません：
https://stackoverflow.com/a/53933849/373542
フェッチプロミスを中止するKISS実装を作成して、結果をここに投稿します。

@ giorgio-zamparelli：_ "並行性は難しいので、テストしないでください" _は完全に元のレポートのポイントを超えています。 この問題は_pending_promiseに関係するのではなく、テストで非同期コードを介してpromise_resolution_が伝播されるのを待つのが不必要に難しいという事実に関係しています。

紅潮の約束は、病気ではなく症状を治すことになると思います。

約束は、フラッシュする必要なしにテストで正常に解決する必要があります。
テストに保留中の約束がある場合は、たとえばwaitから@testing-library/react waitを使用して解決されるのを待つか、保留中の約束がテストの範囲に含まれていない場合は、次のいずれかを行う必要があります。それを開始するコードをモックするか、 AbortControllerを使用してReactwillUnmountライフサイクルイベントのように保留中のpromiseを中止する必要があります

AbortControllerは、ほとんど誰も使用していない新しいAPIであり、テストでのほとんどのハングした約束の修正であると感じています。

私が間違っていることを証明してください：
この問題で保留中の問題の問題を報告した誰かがすでにAbortControllerとjest.mockを使用しようとしていて、それだけでは不十分だった場合、私は簡単に間違っていると証明される可能性があります。

@ giorgio-zamparelli：誤解は、「保留中のすべてのプロミスハンドラーをフラッシュする」というフレーズの使用に起因している可能性があります（そうであれば、申し訳ありません）。 問題の説明をよく読んでいただければ幸いですが、私は「約束の保留中のハンドラー」を意味しました。

したがって、繰り返しになりますが、ここでは（何らかの方法で）_pending_の約束について話しているのではなく、最小限の手間で約束の解決をフラッシュすることについて話しているのです。 または、言い換えると、promiseが解決された時点から、それに関連付けられた後続のすべての効果が呼び出される時点まで、透過的かつ決定論的に取得することについてです（これにより、この結果をテストできます）。

私は最近、この目的のためにflush-microtasksをリリースしました。 それは借り、その実装のソリューション@jwbayよりも驚くほど複雑ですリアクトから、ここまたは@thymikeeのソリューションここに。 複雑さが意味のある違いをもたらすかどうかはわかりませんが、このスレッドの他のソリューションでは考慮されていないエッジケースを説明していると思います。 react-testing-libraryがそれを使用しているため（ここを参照）、その実装のみを使用しましたが、公開していません。

import { flushMicroTasks } from 'flush-microtasks'

await flushMicroTasks()

@ aleclarsonflush -microtasksとflush-promisesに違いはありますか

@ramusus flush-promisesは@jwbayのソリューションと同じアプローチを使用しているように見えます。

https://github.com/kentor/flush-promises/blob/46f58770b14fb74ce1ff27da00837c7e722b9d06/index.js

RTLはReactのコードもコピーしました： https ：

編集：ハァッ、すでに述べた：ニヤリと：

人々がそれを使用できるときに、それをJestに組み込む必要があるかどうかわかりませんか？ たぶん私たちはドキュメントでそれにリンクすることができますか？ この問題は、それらを同期的にフラッシュすることに関するものであり、これは私たちがやりたいことを超えていると思います（特に、 async-awaitでは不可能であるため）

flushPromisesソリューションは、すぐに解決されるPromiseでのみ機能しますが、まだ保留中のPromiseでは機能しません。

うーん、良い点。 どういうわけかpending約束を追跡することが可能かどうかはわかりません。 async_hooksで何か賢いことができるかもしれませんが、確かではありません。 おそらく、ユーザーランドコードによって作成されたプロミスと、Jestとその依存関係によって作成されたプロミスを区別しようとすると苦痛になるでしょう。

Promiseオブジェクトをラップ/モックしてカウンターを含めようとしましたが、機能しません。

const _promise = window.Promise;
window.Promise = function(promiseFunction){
    // counter
    return new _promise(promiseFunction);
}

主な問題は、グローバルPromiseをまったく使用しないasync関数です。

わかりました、私はこのような本当にハッキーな方法を見つけました。

1. リストを使用して新しいモジュールを作成します。
2. そのリストにあなたの約束を追加します。
3. テストでPromiseを解決し、リストから削除します。
4. 私の場合、酵素からwrapper.update()を実行します。 必要に応じて、ここで同様のことを行います。
5. リストが空になるまで、手順3と4を繰り返します。

コードをテストに合わせて調整するのは良い習慣ではありませんが、このロジックはすでにサーバー側のレンダリングで使用しています。 しかし、結局それはただ待っているだけです。 ¯\ _（ツ）_ /¯

Jest 26には、これに対する興味深い更新があります。ここでは、偽のタイマーが@ sinon / fake-timersに基づいています（ jest.useFakeTimers('modern')有効になっている場合）。

私は自分のテストで最新の偽のタイマーを試しましたが、残念ながら、 await new Promise(resolve => setImmediate(resolve));ハックが無期限にハングします。 幸い、 @sinon/fake-timersは、いくつかの*Async()メソッドが含まれています。これらのメソッドは、「イベントループを中断し、スケジュールされたpromiseコールバックがタイマーを実行する前に実行できるようにします」。 残念ながら、JestAPIを介してclockオブジェクトを取得する方法がわかりません。

Jestにclockオブジェクトを提供させる方法を知っている人はいますか？

他の人と同じように、 await new Promise(setImmediate);を使用する私の動機は、解決可能な約束をフラッシュすることです。これにより、システムへの影響を単体テストできます。

「現代の」偽のタイマーは、一見無意味にタイムアウトすることで、実際に他のタイマーよりもパフォーマンスが低いように見えます。

これを説明するためのいくつかのユニットテストは次のとおりです。

describe('flushing of js-queues using different timers', () => {
  beforeAll(() => {
    // It would take the failing test 5 long seconds to time out.
    jest.setTimeout(100);
  });

  it.each([
    [
      'given real timers',
      () => {
        jest.useRealTimers();
      },
    ],
    ['given no timers', () => {}],
    [
      'given "legacy" fake timers',
      () => {
        jest.useFakeTimers('legacy');
      },
    ],
    [
      // This is the the failing scenario, not working like the other timers.
      'given "modern" fake timers',
      () => {
        jest.useFakeTimers('modern');
      },
    ],
  ])(
    '%s, when using setImmediate to flush, flushes a promise without timing out',
    async (_, initializeScenarioSpecificTimers) => {
      initializeScenarioSpecificTimers();

      let promiseIsFlushed = false;

      Promise.resolve().then(() => {
        promiseIsFlushed = true;
      });

      // Flush promises
      await new Promise(setImmediate);

      expect(promiseIsFlushed).toBe(true);
    },
  );
});

前のテストが失敗することはないはずだと思います。

私にとっての回避策は、グローバルな「setImmediate」の代わりに、パッケージ「timers」からノードネイティブの「setImmediate」を使用してpromiseをフラッシュすることでした。 これを持っていると、次のパスがあります。

import { setImmediate as flushMicroTasks } from 'timers';

it('given "modern" fake timers, when using native timers to flush, flushes a promise without timing out', async () => {
  jest.useFakeTimers('modern');

  let promiseIsFlushed = false;

  Promise.resolve().then(() => {
    promiseIsFlushed = true;
  });

  // Flush micro and macro -tasks
  await new Promise(flushMicroTasks);

  expect(promiseIsFlushed).toBe(true);
});

@aleclarsonに感謝します。

この問題の解決策は次のとおりです。

https://github.com/team-igniter-from-houston-inc/async-fn
https://medium.com/houston-io/how-to-unit-test-asynchronous-code-for-javascript-in-2020-41c124be2552

テストコードは次のように書くことができます：

// Note: asyncFn(), extends jest.fn() with a way to control resolving/rejecting of a promise
const load = asyncFn();

const afterLoad = jest.fn();
const result = 'mock result';

mount(<Component load={load} afterLoad={afterLoad} />);

// ... some interaction that requires the `load`

// Note: New way to controlling when promise resolves
await load.resolve(result);

expect(afterLoad).toHaveBeenCalledWith(result);

約束のフラッシュやタイマーの実行について何も知る必要がないことに注意してください。

@jansav nice / +1。 Fwiw私はそのアプローチが据え置きパターンと呼ばれるのを見てきました。 私はそれがより良いテストに役立つと思います。

偽のタイマーの問題は、タイマーがどのように機能するかについての自然な実行ループを壊すことであるように私には思えます。 jestタイマーの実行関数を単純に非同期にすることができないのはなぜですか？ タイマーを変更して同期的に解決することで、テストコードはきれいに見えますが、この大きな副作用が発生します。

私のユースケース：

public static resolvingPromise<T>(result: T, delay: number = 5): Promise<T> {
    return new Promise((resolve) => {
        setTimeout(
            () => {
                resolve(result);
            },
            delay
        );
    });
}

テストファイル：

it("accepts delay as second parameter", async () => {
    const spy = jest.fn();
    MockMiddleware.resolvingPromise({ mock: true }, 50).then(spy);
    jest.advanceTimersByTime(49);
    expect(spy).not.toHaveBeenCalled();
    jest.advanceTimersByTime(1);
    await Promise.resolve(); // without this line, this test won't pass
    expect(spy).toHaveBeenCalled();
});