Jest: Promise 해결 대기열을 플러시하는 API 제공

비동기 테스트가 약속하는 동안 테스트 함수를 약속으로 반환할 수 있으므로 다음과 같이 작동할 수 있음을 기억하는 것이 좋습니다.

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

테스트 함수에서 약속을 반환하면 Jest가 이것이 비동기 테스트임을 인식하고 해결되거나 시간 초과될 때까지 대기합니다.

@thymikee 물론 Jest가 기다리게 하기 위해 값을 반환하고 있습니다. 이는 요점에서 완전히 벗어났습니다. 코드에서 .then(() => {}) 행을 어떻게 남겼는지 주목하십시오. 시작 게시물에서 이미 했던 것보다 문제를 더 간결하게 설명하는 방법을 모르겠습니다. 자세히 읽고 문제를 다시 열거나 해결 방법을 설명하십시오.

_혼동을 피하기 위해 OP의 코드에 return 를 추가했습니다._

비슷한 문제가 발생하여 여기에 설명되어 있습니다. https://github.com/pekala/test-problem-example

간단히 말해서: 사용자 상호 작용(효소를 사용하여 시뮬레이션)의 결과로 Redux 저장소에 파견된 일련의 작업을 주장하려고 합니다. Promises를 사용하여 디스패치된 동기화 및 비동기 작업(즉시 해결되도록 조롱). Promise 체인에 직접 액세스할 수 없는 경우 Promise 체인이 소진된 후 주장할 방법이 없는 것 같습니다. setTimeout(..., 0) 는 작동하지만 해킹된 것처럼 느껴지며 setTimeout 콜백의 주장이 실패하면 Jest가 시간 초과 오류(어설션 오류 대신)와 함께 실패합니다.

flushAllPromises 의 아이디어는 해결책처럼 보이지만 그것이 runAllTicks 가 해야 할 일이라고 생각합니다.

후속 조치로: setTimeout(..., 0) 를 setImmediate 바꾸려고 시도했는데 Promise 콜백 마이크로태스크 대기열이 소진된 후 어설션을 실행하고 Jest가 어설션 오류에서 시간 초과되는 것을 방지하는 것 같습니다. 따라서 이것은 제대로 작동하며 내 사용 사례에 적합한 솔루션입니다.

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

도우미 함수는 이를 약속 자체로 바꿀 수 있으므로 완료된 콜백을 처리할 필요가 없습니다. 그것은 사용자 영역에 보관하기에 꽤 무해할 만큼 충분히 작지만 농담 대상에 올려 놓으면 불평하지 않을 것입니다. 이와 같은 것이 내 프로젝트에서 많이 사용됩니다.

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

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

async await를 사용하면 거의 아름답습니다.

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

@jwbay 거기에 좋은 설탕이 있어요 🍠!

이 flushPromises 이 한 줄

@pekala one liner IMO는 다음 보류 중인 약속이 해결될 때까지 기다리지 않기 때문에 필요한 동작을 제공하지 않습니다.

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

Swizzling Promise는 어떻고 새로운 Promise가 생성되면 배열에 추가한 다음 모든 Promise를 플러시하면 이 배열의 Promise.all에서 기다립니다.

@talkol 당신이 가짜 타이머를 사용하는 한 그럴 것이라고 생각합니다. 나는 그것을 테스트하지 않았습니다.

@pekala 이 예제에서는 시간에 도달한 후에만 약속이 해결되므로 타이머를
나는 swizzling Promise가 농담 내부 작동을 엉망으로 만들지 않을까 걱정합니다. 약간 하드 코어입니다.

가짜 타이머를 사용하지 않으면 테스트를 완료하는 데 실제 2초 이상이 걸립니다. 가장 좋은 방법은 이러한 유형의 지연을 제거하는 것입니다. 이 경우 @jwbay 가 제안한 flushPromises 가 작업을 수행합니다.

모두 당신이 테스트하려는 것에 달려 있습니다 :) 내가 말하는 것은 타이머가 약속을 기다리는 것과 관련이 없다는 것입니다.

setTimeout 호출과 혼합되어 해결되지 않는 약속과 관련된 문제가 발생했습니다. jest v19.0.2에서는 문제가 없지만 jest v20.0.0에서는 Promise가 해결/거부 기능에 들어가지 않으므로 테스트가 실패합니다. 우리의 문제는 _약속 해결 대기열을 플러시하는 API가 없는 이 문제와 관련이 있는 것 같습니다. 그러나 이 문제는 우리가 문제를 보기 시작한 jest v20.0.0보다 이전인 것 같으므로 확실하지 않습니다.

우리가 교류하는 일련의이 있기 때문에 이것은 우리가 올 업에 대한 우리의 테스트의 일부와 수 있었던 유일한 솔루션입니다 setTimeout 및 S Promise 코드에 사용의 결국을 부르는을 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.');
    });

그렇게 예쁘지 않으므로 여기에 있는 어떤 조언도 대단히 감사합니다.

테스트에서 약속을 반환할 수 없는 또 다른 예:

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

이 테스트는 jest 20.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.all을 사용하는 코드를 테스트하고 있습니다. 래핑된 약속 중 하나가 실패하면(이것이 제가 테스트하려는 것이기 때문에) 다음 테스트가 실행되는 동안 다른 약속(경합 조건, 비결정적)이 반환된다는 의미로 즉시 약속이 반환됩니다.

이것은 내 테스트가 예측할 수 없거나 반복할 수 없는 결과를 갖는 모든 종류의 혼란을 야기합니다.

이것을 적절하게 구현하려면 Promise 를 모의해야 하므로 결국에는 대기열에 있는 모든 마이크로 작업을 확인하여 동기식으로 해결할 수 있습니다. promise-mock 이 하는 일을 방해하는 것입니다.

process.nextTick 대기열에 있는 마이크로 작업을 플러시하는 API가 이미 있으며 해당 API는 아마도 Promises( jest.runAllTicks )와도 작동해야 합니다.

나는 약속 라이브러리인 nextTick of Yaku에 연결되어 nextTick 호출을 포착하고 조기에 재생할 수 있는 재스민 솔루션을 가지고 있었습니다.
그러나 농담은 약속 자체를 사용하므로 이것이 문제가 됩니다.
결국 나는 Yaku를 해킹하여 대기열을 플러시하는 플러시 방법을 사용했습니다. 기본적으로 nextTick을 사용하여 정상적으로 실행되지만 flush를 호출하면 보류 중인 모든 약속 핸들러가 실행됩니다.
출처는 다음과 같습니다.
https://github.com/lukeapage/yaku-mock
정리하고, ysmood에 연락하여 그것에 대해 어떻게 생각하는지 확인하고 문서를 추가하는 것과 관련이 있을 수 있지만, 원하는 작업을 거의 수행하고 테스트에서 약속을 동기화하는 간단한 솔루션으로 저를 위해 일했습니다.

이에 대한 간단한 해결 방법으로 @jwbay 의 솔루션이 마음에

jest 객체와 유사한 것을 추가하는 것은 어떻습니까?

await jest.nextTick();

다음과 같이 구현

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

cc @cpojer @SimenB @rogeliog

React 구성 요소를 마운트하기 위해 효소를 사용하고 있습니다.

나에게도 Promise가 실행될 것으로 예상하는 기능이 있지만 앞서 언급한 수정 사항 중 어느 것도 작동하지 않았습니다. 내 테스트에서 동기적으로 처리할 수 있습니다. - if - 함수가 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(...)
});

나는 이것에 대한 사용 사례를 만났습니다 (멋진 기술에 대해

예를 들어 함수에 시간 초과가 있는지 확인하고 시간 초과가 정확하게 적용되었는지 확인하려고 합니다.

      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 를 추가해야 하지만 이것은 제대로 작동합니다.

내가 이 접근 방식을 사용하지 말아야 하는 이유가 있거나 이것이 사람들에게 좋게 보이는 이유가 있습니까?

나는 userland에서 이것을 하는 모험을 했고 그것이 실제로 가능하고 그렇게 나쁘지 않다는 것을 발견했습니다. 다음은 직접 사용하기에 충분히 자세한 경험 보고서입니다 . TLDR은 async / await 를 프라미스로 변환하고 기본 프라미스를 블루버드로, 기본 타이머를 로렉스로 바꾸는 것입니다. node_modules/ 포함한 모든 것을 트랜스파일 ; queueMicrotask 프라미스에 필요한 기본 요소이지만 기본적으로 lolex는 JSDOM이 제공하지 않기 때문에 기본적으로 제공하지 않습니다.

jest.mockAllTimers() 및 Promise 에서 componentDidMount() Promise 를 호출하는 React 구성 요소에서 동일한 문제가 발생했습니다.

#issuecomment-279171856 의 솔루션은 문제를 우아한 방식으로 해결했습니다.

우리는 공식 Jest API에서 비슷한 것이 필요합니다!

나는 최근에 많은 것들을 업그레이드하는 동안 문제에 부딪쳤습니다. 그것은 우리가 약속이 끝날 때까지 항상 기다리지 않았던 많은 테스트에서 문제를 드러냈습니다. 그리고 await new Promise(resolve => setImmediate(resolve)); 와 같은 메소드가 간단한 경우에 작동했지만 테스트에서 발견했지만 파이프를 지우려면 몇 번 실행해야 합니다. @quasicomputational이 여기 에서 탐색 promise-spy . 그러나 가짜 타이머를 사용하는 테스트가 하나 있었는데 작동하지 않았습니다...그래서 아직 완전히 작동하는 솔루션은 아닙니다.

나는 또한 그들이 약속으로 변환되는 경우 테스트할 코드의 async / await 와 함께 작동할 수도 있다고 상상합니다. 약속으로 변환되지 않으면 이 라이브러리는 약속에 연결하여 완료될 때까지 기다릴 수 없습니다.

나는이 같은 문제가 있음을 발견하고 깨달았습니다.
보류 중인 프라미스를 플러시하지 말고 대신 보류 중인 프라미스가 있는 경우 전체 테스트가 실패하도록 해야 합니다.
이렇게 하면 Abort Controller를 사용하여 테스트된 코드 내에서 보류 중인 약속을 강제로 중단할 수 있습니다.
https://developers.google.com/web/updates/2017/09/abortable-fetch
농담을 던지는 약속을 갖는 것은 "동시성은 어렵기 때문에 테스트하지 말자"라고 말하는 것과 같습니다. 실제로는 정반대여야 합니다.
동시성은 어렵기 때문에 더 많이 테스트해야 하고 보류 중인 약속으로 테스트를 통과하는 것을 전혀 허용하지 않아야 합니다.

이 Stackoverflow 질문에 대한 약속을 중단하는 혼란을 감안할 때 (아직) 쉬운 일이 아닙니다.
https://stackoverflow.com/a/53933849/373542
내 가져오기 약속을 중단하는 KISS 구현을 작성하려고 하고 결과를 여기에 게시할 것입니다.

@giorgio-zamparelli: _"동시성은 어렵기 때문에 테스트하지 말자"_는 원래 보고서의 요지에서 완전히 벗어났습니다. 이 문제는 _pending_ Promise와 관련된 것이 아니라 테스트에서 비동기 코드를 통해 Promise _resolution_ 전파를 기다리는 것이 불필요하게 어렵다는 사실과 관련이 있습니다.

홍조 약속이 질병 대신 증상을 치료할 것이라고 생각합니다.

Promise는 플러시할 필요 없이 테스트에서 정상적으로 해결되어야 합니다.
테스트에 보류 중인 프라미스가 있는 경우 wait from @testing-library/react 사용하여 해결될 때까지 기다리거나 보류 중인 프라미스가 테스트 범위의 일부가 아니면 다음 중 하나를 수행해야 합니다. 시작하는 코드를 조롱하거나 AbortController 사용하여 React willUnmount 수명 주기 이벤트와 같은 곳에서 보류 중인 약속을 중단해야 합니다.

AbortController는 거의 아무도 사용하지 않는 새로운 API이며 테스트에서 매달려 있는 대부분의 약속에 대한 수정 사항이라고 생각합니다.

내가 틀렸다는 것을 증명 해봐:
이 문제에서 보류 중인 문제에 문제가 있다고 보고한 사람이 이미 AbortController 및 jest.mock을 사용해 보았지만 충분하지 않은 경우 내가 틀렸다는 것이 쉽게 증명될 수 있습니다.

@giorgio-zamparelli: 아마도 오해는 _"대기 중인 모든 약속 처리기를 플러시"_라는 문구를 사용한 데서 비롯된 것 같습니다(그렇다면 죄송합니다). 문제 설명을 자세히 읽으면 알 수 있듯이 "대기 중인 약속 처리기"를 의미했습니다.

따라서 반복해서 말씀드리자면, 여기서 우리는 _pending_ promise에 대해 (어떤 식으로든) 이야기하는 것이 아니라 최소한의 번거로움으로 promise 해결을 플러시하는 것에 대해 이야기하고 있습니다. 또는 다른 말로 하면, 프라미스가 해결되는 지점에서 그것에 연결된 모든 후속 효과가 호출되는 지점까지 투명하고 결정론적으로 도달하는 것입니다(이 결과를 테스트할 수 있도록).

저는 최근에 이를 위해 flush-microtasks 를 출시했습니다. 그것은 차용 구현 의 솔루션 @jwbay에 비해 놀라 울 정도로 복잡하다 반작용에서, 여기 또는 @thymikee의 솔루션 여기를 . 복잡성이 의미 있는 차이를 만드는지 여부는 확실하지 않지만 이 스레드의 다른 솔루션에서 고려하지 않은 극단적인 경우를 설명한다고 가정합니다. react-testing-library 사용하기 때문에 해당 구현 here 참조). 그러나 노출하지 않습니다.

import { flushMicroTasks } from 'flush-microtasks'

await flushMicroTasks()

@aleclarson 플러시 마이크로 작업과 플러시 약속 사이에 차이점이 있습니까?

@ramusus flush-promises 은 @jwbay 의 솔루션과 동일한 접근 방식을 사용하는 것 같습니다.

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

RTL은 또한 React의 코드를 복사했습니다: https://github.com/testing-library/react-testing-library/blob/8db62fee6303d16e0d5c933ec1fab5841dd2109b/src/flush-microtasks.js

편집: 하, 이미 언급했습니다.

사람들이 그것을 사용할 수 있을 때 Jest에 빌드해야 하는지 잘 모르겠습니다. 문서에서 링크할 수 있을까요? 이 문제는 동기적으로 플러시하는 것에 관한 것인데, 이는 우리가 원하는 것 이상이라고 생각합니다(특히 async-await 불가능하기 때문에).

flushPromises 솔루션은 즉시 해결되지만 아직 보류 중인 약속에는 작동하지 않습니다.

흠, 좋은 지적입니다. pending 약속을 어떻게든 추적할 수 있는지 모르겠습니다. async_hooks 영리한 일을 할 수 있을지도 모릅니다. 확실하지 않습니다. 아마도 userland 코드에 의해 생성된 promise와 Jest와 그 의존성에 의해 생성된 promise를 구별하는 것은 고통스러울 것입니다.

카운터를 포함하도록 Promise 개체를 래핑/모의하려고 시도했지만 작동하지 않습니다.

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

주요 문제는 전역 Promise 을 전혀 사용하지 않는 async 함수입니다.

좋아, 나는 이것 과 같은 정말 해킹 방법을 찾았습니다.

1. 목록이 있는 새 모듈을 만듭니다.
2. 그 목록에 약속을 추가하십시오.
3. 테스트에서 약속을 해결하고 목록에서 제거하십시오.
4. 제 경우에는 효소에서 wrapper.update() 를 실행합니다. 필요한 경우 여기에서 비슷한 작업을 수행합니다.
5. 목록이 비어 있을 때까지 3단계와 4단계를 반복합니다.

테스트에 맞게 코드를 조정하는 것은 좋은 방법이 아니지만 이미 서버 측 렌더링에서 이 논리를 사용하고 있습니다. 하지만 결국은 기다릴 뿐입니다. ¯\_(ツ)_/¯

Jest 26에는 이에 대한 흥미로운 업데이트가 있습니다. 여기서 가짜 타이머는 이제 @sinon/fake-timers를 기반으로 합니다 ( jest.useFakeTimers('modern') 활성화된 경우).

내 테스트로 최신 가짜 타이머를 시도했지만 불행히도 await new Promise(resolve => setImmediate(resolve)); 해킹이 무기한 중단됩니다. 다행스럽게도 @sinon/fake-timers 에는 "이벤트 루프도 중단하여 예약된 약속 콜백이 타이머를 실행하기 _전에_ 실행할 수 있는" 몇 가지 *Async() 메서드가 포함되어 있습니다. 불행히도 Jest API를 통해 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"를 사용하여 약속을 플러시하는 것이었습니다. 이를 통해 다음을 통과합니다.

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 멋지다/+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();
});