Jest: वादा समाधान कतार को फ्लश करने के लिए एक एपीआई प्रदान करें

जबकि async परीक्षण वादा करता है, यह याद रखना अच्छा है कि आप एक परीक्षण फ़ंक्शन को एक वादे के रूप में वापस कर सकते हैं, इसलिए ऐसा कुछ काम करेगा:

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

परीक्षण फ़ंक्शन से एक वादा वापस करने से जेस्ट को पता चलता है कि यह एक एसिंक परीक्षण है और इसे हल होने या समय समाप्त होने तक प्रतीक्षा करना है।

@thymikee बेशक मैं जेस्ट प्रतीक्षा करने के लिए मूल्य वापस कर रहा हूं - यह पूरी तरह से बिंदु से बाहर है। ध्यान दें कि आपने अपने कोड में .then(() => {}) लाइन को कैसे छोड़ा। मैं यह नहीं देखता कि मैं समस्या का अधिक संक्षेप में वर्णन कैसे कर सकता हूँ जितना मैंने पहले पोस्ट में किया था। कृपया इसे पूरी तरह से पढ़ें और या तो इस मुद्दे को फिर से खोलें या वर्णन करें कि इसे कैसे हल किया जाए।

_मैंने भ्रम से बचने के लिए OP में कोड में return जोड़ा है।_

इसी तरह की समस्या में भाग गया, और इसे यहाँ वर्णित किया: https://github.com/pekala/test-problem-example

संक्षेप में: मैं उपयोगकर्ता इंटरैक्शन (एंजाइम का उपयोग करके नकली) के परिणामस्वरूप Redux स्टोर पर भेजे गए कार्यों के अनुक्रम पर जोर देने की कोशिश कर रहा हूं। वादों का उपयोग करके भेजे गए सिंक और एसिंक्स के रूप में क्रियाएं (तुरंत हल करने के लिए मजाक उड़ाया गया)। ऐसा लगता है कि वादा श्रृंखला समाप्त होने के बाद दावा करने का कोई तरीका नहीं है, अगर आपके पास वादा श्रृंखला तक सीधी पहुंच नहीं है। setTimeout(..., 0) काम करता है, लेकिन यह हैकी लगता है और यदि setTimeout के कॉलबैक में दावा विफल हो जाता है, तो जेस्ट टाइमआउट त्रुटि (अभिकथन त्रुटि के बजाय) के साथ विफल हो जाता है।

flushAllPromises का विचार एक समाधान की तरह लगता है, हालांकि मुझे लगता है कि runAllTicks को यही करना चाहिए?

फॉलो-अप के रूप में: मैंने setTimeout(..., 0) को setImmediate setTimeout(..., 0) साथ बदलने की कोशिश की और ऐसा लगता है कि वादा कॉलबैक माइक्रोटास्क कतार समाप्त होने के बाद दोनों दावे चलाते हैं और जेस्ट को दावा त्रुटियों पर समय समाप्त होने से रोकता है। तो, यह ठीक काम करता है, और मेरे उपयोगकेस के लिए एक स्वीकार्य समाधान है:

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 के साथ प्रतीक्षा करें यह लगभग सुंदर है:

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

@jwbay वहीं कुछ अच्छी चीनी है !

यह सच है कि यह flushPromises एक-लाइनर निकला, लेकिन यह बिल्कुल भी स्पष्ट नहीं है कि उस एक पंक्ति तक कैसे पहुंचा जाए। इसलिए मुझे लगता है कि जेस्ट उपयोगकर्ताओं के लिए इसे एक उपयोग समारोह के रूप में उपलब्ध कराना एक लाभ होगा।

@pekala वन लाइनर IMO आवश्यक व्यवहार प्रदान नहीं करता है क्योंकि यह निम्नलिखित लंबित वादे के हल होने तक प्रतीक्षा नहीं करेगा:

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

स्विज़लिंग प्रॉमिस के बारे में क्या है और जब एक नया प्रॉमिस बनाया जाता है तो उसे कुछ ऐरे में जोड़ें, फिर सभी वादों को प्रॉमिस पर फ्लश करें। इस ऐरे में सभी वादे?

@talkol मुझे लगता है कि यह तब तक होगा, जब तक आप हमें नकली टाइमर भी देंगे। मैंने हालांकि इसका परीक्षण नहीं किया है।

@pekala इस उदाहरण के साथ नकली टाइमर की कोई आवश्यकता नहीं है क्योंकि वादा समय पूरा होने के बाद ही हल होगा
मुझे बस इस बात की चिंता है कि स्विज़लिंग प्रॉमिस मज़ाक के अंदरूनी कामकाज के साथ खिलवाड़ करेगा, यह थोड़ा कठिन है

यदि आप नकली टाइमर नहीं बनाते हैं, तो आपके परीक्षणों को पूरा होने में वास्तविक 2s+ लगेंगे। मुझे लगता है कि इस प्रकार की देरी को दूर करने के लिए सबसे अच्छा अभ्यास होगा, इस मामले में @jwbay द्वारा प्रस्तावित flushPromises काम करता है।

सब कुछ इस बात पर निर्भर करता है कि आप क्या परीक्षण करने की कोशिश कर रहे हैं :) मैं केवल इतना कह रहा हूं कि टाइमर वादे की प्रतीक्षा करने के लिए एक असंबंधित चिंता है

हम वादे से संबंधित मुद्दों को हल नहीं कर रहे हैं, जो सेटटाइमआउट कॉल के साथ मिश्रित हैं। जेस्ट v19.0.2 में हमें कोई समस्या नहीं है, लेकिन जेस्ट v20.0.0 में वादे कभी भी संकल्प / अस्वीकार कार्यों में प्रवेश नहीं करते हैं और इसलिए परीक्षण विफल हो जाते हैं। हमारा मुद्दा इस मुद्दे से संबंधित प्रतीत होता है कि प्रॉमिस रेजोल्यूशन कतार_ ​​को फ्लश करने के लिए _an एपीआई नहीं है, लेकिन यह मुद्दा जेस्ट 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.');
    });

इतना सुंदर नहीं है, इसलिए यहां किसी भी सलाह की बहुत सराहना की जाती है।

एक और उदाहरण जहां आप परीक्षण से वादा वापस नहीं कर सकते:

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

यह परीक्षण जेस्ट 20.0.4 के साथ विफल हो जाता है।

@philwhln का समाधान भी async/प्रतीक्षा के साथ लिखा जा सकता है

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 का उपहास करना होगा ताकि हम अंततः सभी संलग्न सूक्ष्म कार्यों को समकालिक रूप से हल करने के लिए देख सकें। वादे-मजाक क्या कर रहा है के रास्ते में कुछ।

process.nextTick साथ संलग्न सूक्ष्म कार्यों को फ्लश करने के लिए पहले से ही एक एपीआई है और उस एपीआई को शायद वादे ( jest.runAllTicks ) के साथ भी काम करना चाहिए।

मेरे पास चमेली के साथ एक समाधान था जो याकू के अगले टिक, एक वादा पुस्तकालय में जुड़ा हुआ था और अगली टिक कॉलों को पकड़ा और उन्हें जल्दी खेलने की अनुमति दी।
हालाँकि, मज़ाक स्वयं वादों का उपयोग करता है, जिसने इसे समस्याग्रस्त बना दिया।
अंत में मैंने याकू को ले लिया और उसे हैक कर लिया ताकि एक फ्लश विधि हो जो उसकी कतार को हटा दे। डिफ़ॉल्ट रूप से यह सामान्य रूप से अगली टिक का उपयोग करता है, लेकिन यदि आप फ्लश को कॉल करते हैं तो सभी लंबित वादे हैंडलर निष्पादित होते हैं।
स्रोत यहाँ है:
https://github.com/lukeapage/yaku-mock
यह साफ करने, ysmood से संपर्क करके यह देखने के लिए कर सकता है कि वे इसके बारे में क्या सोचते हैं और दस्तावेज़ीकरण जोड़ते हैं, लेकिन यह बहुत कुछ करता है जो आप चाहते हैं और परीक्षणों में वादों को सिंक करने के लिए एक सरल समाधान के रूप में मेरे लिए काम किया।

इसके लिए एक साधारण समाधान के रूप में मुझे @jwbay का समाधान पसंद है।

हम jest ऑब्जेक्ट के समान कुछ कैसे जोड़ेंगे?

await jest.nextTick();

के रूप में लागू किया गया

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

cc @cpojer @SimenB @rogeliog

मैं प्रतिक्रिया घटकों को माउंट करने के लिए एंजाइम का उपयोग कर रहा हूं।

मेरे पास भी ऐसे कार्य हैं जो वादे को निष्पादित करने की अपेक्षा करते हैं, लेकिन उपर्युक्त सुधारों में से कोई भी काम नहीं करता है। मैं उन्हें अपने परीक्षण में समकालिक रूप से संभालने में सक्षम होगा - अगर - कार्यों ने वादा वस्तुओं को वापस कर दिया, await का उपयोग करके, लेकिन दुर्भाग्य से फ़ंक्शन वादा वस्तुओं को वापस नहीं करते हैं।

यह वह समाधान है जिसे मैंने वैश्विक प्रॉमिस फ़ंक्शन पर एक जासूस का उपयोग करके समाप्त किया।

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

एक वादा वापस करने से संकल्प/अस्वीकृति के सटीक समय की जांच करने की अनुमति नहीं मिलती है।

वहां एक वादा फ्लशिंग की जरूरत है। इसके बिना, अपेक्षा को बहुत जल्दी कहा जाता है।

आशा है कि इससे समस्या को कम करने में मदद मिलेगी।

साथ चलने वाले लोगों के लिए, यहां इसके लिए एक खुला पीआर है: #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)
})

मुझे एक समस्या थी जब एसिंक कॉल सीधे कंपोनेंटडिडमाउंट में नहीं किया गया था, लेकिन यह एक एसिंक्स फ़ंक्शन को कॉल कर रहा था, जो एक और एसिंक फ़ंक्शन को कॉल कर रहा था और इसी तरह। अगर मैंने सभी एसिंक श्रृंखला में एक अतिरिक्त एसिंक चरण जोड़ा है, तो मुझे अतिरिक्त .then() या अतिरिक्त await जोड़ना होगा, लेकिन यह ठीक काम कर रहा है।

क्या कोई कारण है कि मुझे इस दृष्टिकोण का उपयोग नहीं करना चाहिए या क्या यह लोगों को अच्छा लगता है?

मैं उपयोगकर्तालैंड में ऐसा करने में एक साहसिक कार्य पर गया और पाया कि यह वास्तव में करने योग्य है और इतना बुरा नहीं है (हालांकि यदि आपके पास नक्शा नहीं है तो इसमें कुछ नुकसान हो सकते हैं)। यहां एक अनुभव रिपोर्ट है जो (उम्मीद है) सीधे उपयोग करने के लिए पर्याप्त विस्तृत है ; एक TLDR async / await को वादों के नीचे ट्रांसपाइल करना है, और लोलेक्स के लिए ब्लूबर्ड और देशी टाइमर के लिए मूल वादों को स्वैप करना है; node_modules/ सहित सब कुछ पारदर्शी करें; queueMicrotask वादों के लिए आपको आवश्यक आदिम है, लेकिन डिफ़ॉल्ट रूप से लोलेक्स इसे प्रदान नहीं करेगा क्योंकि JSDOM इसे प्रदान नहीं करता है।

मैं jest.mockAllTimers() और रिएक्ट घटकों के साथ एक ही मुद्दे में भाग गया जो Promise में componentDidMount() ।

#issuecomment-279171856 से समाधान ने समस्या को एक सुंदर तरीके से हल किया।

हमें आधिकारिक जेस्ट एपीआई में कुछ ऐसा ही चाहिए!

मैं हाल ही में सामानों के एक समूह को अपग्रेड करते समय एक समस्या में भाग गया, इसने परीक्षणों के एक समूह में एक समस्या का खुलासा किया जहां हम हमेशा वादे खत्म होने की प्रतीक्षा नहीं कर रहे थे। और जबकि await new Promise(resolve => setImmediate(resolve)); जैसी विधियों ने साधारण मामलों में काम किया, मैंने अपने परीक्षणों में पाया, मुझे पाइप को साफ़ करने के लिए इसे कुछ बार चलाना होगा। जिसका उल्लेख @quasicomputational ने अपने अन्वेषण में यहाँ किया है । दुर्भाग्य से, मुझे नहीं लगता कि यह जानने का कोई तरीका है कि जब वह पाइप वादों को बनाए जाने के दौरान उन्हें बाधित किए बिना स्पष्ट होता है। तो मैंने ऐसा करने के लिए एक छोटी सी लाइब्रेरी बनाई... वादा-जासूस । हालांकि, मेरे पास एक परीक्षण था जो नकली टाइमर का उपयोग कर रहा था और यह उसके साथ काम नहीं करता था ... इसलिए यह अभी तक पूरी तरह से काम करने वाला समाधान नहीं है।

हालांकि मैं यह भी कल्पना करता हूं कि वे आपके कोड में केवल async / await साथ काम कर सकते हैं यदि वे वादों के लिए पारदर्शी हैं। यदि उन्हें वादों पर नहीं पहुँचाया जाता है, तो यह पुस्तकालय उनमें शामिल नहीं हो पाएगा और उनके पूरा होने की प्रतीक्षा नहीं कर पाएगा।

मैंने खुद को यही मुद्दा पाया और मुझे एहसास हुआ:
हमें लंबित वादों को पूरा नहीं करना चाहिए, बल्कि लंबित वादों के होने पर हमें पूरी परीक्षा विफल कर देनी चाहिए।
इस तरह हम निरस्त नियंत्रक का उपयोग करके परीक्षण किए गए कोड के अंदर लंबित वादों को निरस्त करने के लिए मजबूर होंगे:
https://developers.google.com/web/updates/2017/09/abortable-fetch
जस्ट फ्लशिंग वादों को कहने के बराबर है "Concurrency कठिन है तो चलिए इसका परीक्षण नहीं करते हैं"। हकीकत में यह बिल्कुल विपरीत होना चाहिए।
चूंकि समेकन कठिन है, इसलिए हमें इसका और भी अधिक परीक्षण करना चाहिए और लंबित वादों के साथ किसी भी परीक्षा को पास नहीं होने देना चाहिए।

इस स्टैक ओवरफ्लो प्रश्न पर वादों को रद्द करने की गड़बड़ी को देखते हुए स्पष्ट नहीं है (YET) एक आसान काम है:
https://stackoverflow.com/a/53933849/373542
मैं अपने फ़ेच वादों को निरस्त करने के लिए एक KISS कार्यान्वयन लिखने की कोशिश करने जा रहा हूँ और यहाँ परिणाम पोस्ट करूँगा।

@ giorgio-zamparelli: _ "Concurrency कठिन है तो चलिए इसका परीक्षण नहीं करते हैं"_ मूल रिपोर्ट के बिंदु के बिल्कुल बगल में है। मुद्दा _लंबित_ वादों से संबंधित नहीं है, बल्कि इस तथ्य से संबंधित है कि परीक्षणों में async कोड के माध्यम से वादे _resolution_ के प्रचार की प्रतीक्षा करना अनावश्यक रूप से कठिन है।

मुझे लगता है कि फ्लशिंग वादे बीमारी के बजाय लक्षणों को ठीक कर देंगे।

वादों को बिना फ्लश किए परीक्षणों में सामान्य रूप से हल करना चाहिए।
यदि आपके परीक्षण में कोई लंबित वादा है, तो आपको या तो इसके समाधान के लिए प्रतीक्षा करनी चाहिए उदाहरण के लिए wait से @testing-library/react या यदि लंबित वादा परीक्षण के दायरे का हिस्सा नहीं है तो आपको या तो करना चाहिए इसे शुरू करने वाले कोड का मजाक उड़ाएं या आपको AbortController का उपयोग करके रिएक्ट विलअनमाउंट जीवनचक्र घटना की तरह कहीं भी लंबित वादे को रद्द कर देना चाहिए

एबॉर्टकंट्रोलर एक नया एपीआई है जिसका लगभग कोई भी उपयोग नहीं कर रहा है और मुझे लगता है कि परीक्षणों में अधिकांश लटके हुए वादों के लिए यह ठीक है।

मुझे गलत साबित करें:
मैं आसानी से गलत साबित हो सकता हूं अगर किसी ने इस मुद्दे में लंबित समस्याओं के साथ समस्या होने की सूचना दी है तो पहले से ही AbortController और jest.mock का उपयोग करने का प्रयास किया है और यह पर्याप्त नहीं था।

@ जियोर्जियो-ज़म्परेली: हो सकता है कि गलतफहमी मेरे वाक्यांश _ "फ्लश सभी लंबित वादे हैंडलर" के उपयोग से उत्पन्न होती है (और यदि ऐसा होता है, तो मुझे खेद है)। जैसा कि आप उम्मीद से देखेंगे कि क्या आपने समस्या विवरण को अच्छी तरह से पढ़ा है, मेरा मतलब है "वादों के लंबित हैंडलर"।

इसलिए, दोहराने के लिए, हम यहां (किसी भी तरह से) _लंबित_ वादों के बारे में बात नहीं कर रहे हैं, बल्कि न्यूनतम परेशानी के साथ वादा समाधान को फ्लश करने के बारे में बात कर रहे हैं। या, दूसरे शब्दों में, उस बिंदु से पारदर्शी और निश्चित रूप से प्राप्त करने के बारे में जहां एक वादा उस बिंदु तक हल हो जाता है जहां उसके बाद के सभी प्रभाव लागू होते हैं (ताकि हम इसके परिणाम का परीक्षण कर सकें)।

मैंने हाल ही में इस उद्देश्य के लिए flush-microtasks जारी किया है। यह उधार लेता है इसके कार्यान्वयन प्रतिक्रिया से है, जो @jwbay से आश्चर्यजनक रूप से अधिक जटिल है के समाधान यहाँ या @thymikee के समाधान यहाँ । मुझे यकीन नहीं है कि जटिलता कोई सार्थक अंतर बनाती है, लेकिन मुझे लगता है कि यह इस धागे में अन्य समाधानों द्वारा विचार नहीं किए गए किनारे के मामलों के लिए जिम्मेदार है। मैंने केवल उस कार्यान्वयन का उपयोग किया क्योंकि react-testing-library इसका उपयोग करता है (देखें यहां ), लेकिन इसका खुलासा नहीं करता है।

import { flushMicroTasks } from 'flush-microtasks'

await flushMicroTasks()

@aleclarson फ्लश-माइक्रोटास्क और फ्लश-वादों के बीच कोई अंतर है

@ramusus ऐसा लगता है कि flush-promises @jwbay के समाधान के समान दृष्टिकोण का उपयोग करता है।

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

आरटीएल ने रिएक्ट का कोड भी कॉपी किया है: https://github.com/testing-library/react-testing-library/blob/8db62fee6303d16e0d5c933ec1fab5841dd2109b/src/flush-microtasks.js

संपादित करें: हा, पहले ही उल्लेख किया गया है: मुस्कुराते हुए:

मुझे यकीन नहीं है कि जब लोग इसका इस्तेमाल कर सकते हैं तो हमें इसे जेस्ट में बनाने की ज़रूरत है? शायद हम इसे डॉक्स में लिंक कर सकते हैं? यह मुद्दा उन्हें समकालिक रूप से फ्लश करने के बारे में है, जो मुझे लगता है कि हम जो करना चाहते हैं उससे परे है (विशेष रूप से async-await साथ असंभव है)

flushPromises समाधान केवल उन वादों पर काम करता है जो तुरंत हल हो जाते हैं लेकिन उन पर नहीं जो अभी भी लंबित हैं।

हम्म, अच्छा बिंदु। मुझे नहीं पता कि किसी तरह pending वादों को ट्रैक करना संभव है या नहीं। async_hooks साथ कुछ चतुर करने में सक्षम हो सकता है, निश्चित नहीं है। संभवत: यूजरलैंड कोड द्वारा बनाए गए वादों और जेस्ट और उसकी निर्भरता द्वारा बनाए गए वादों के बीच अंतर करने की कोशिश करना दर्दनाक होगा

मैंने काउंटर को शामिल करने के लिए Promise ऑब्जेक्ट को लपेटने/नकली करने का प्रयास किया है लेकिन यह काम नहीं करता है:

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

मुख्य मुद्दा async फ़ंक्शंस है जो वैश्विक Promise बिल्कुल भी उपयोग नहीं करते हैं

ठीक है, मुझे इस तरह का एक बहुत ही आसान तरीका मिल गया है।

1. सूची के साथ एक नया मॉड्यूल बनाएं।
2. उस सूची में अपने वादे जोड़ें।
3. अपने परीक्षण में वादों को हल करें और उन्हें सूची से हटा दें।
4. मेरे मामले में मैं एंजाइम से wrapper.update() चलाता हूं। जरूरत पड़ने पर यहां भी कुछ ऐसा ही करें।
5. चरण 3 और 4 को तब तक दोहराएं जब तक सूची खाली न हो जाए।

मुझे पता है, परीक्षणों में कोड समायोजित करना एक अच्छा अभ्यास नहीं है लेकिन मैं पहले से ही सर्वर साइड प्रतिपादन पर इस तर्क का उपयोग करता हूं। लेकिन अंत में बस इंतजार है। \_(ツ)_/¯

जेस्ट 26 में इसके लिए एक दिलचस्प अपडेट है, जहां नकली टाइमर अब @sinon/नकली-टाइमर पर आधारित हैं (यदि jest.useFakeTimers('modern') साथ सक्षम है)।

मैंने अपने परीक्षणों के साथ आधुनिक नकली टाइमर की कोशिश की, और दुर्भाग्य से यह await new Promise(resolve => setImmediate(resolve)); हैक को अनिश्चित काल तक लटका देता है। सौभाग्य से, @sinon/fake-timers में कई *Async() विधियां शामिल हैं जो "इवेंट लूप को भी तोड़ देंगी, जिससे किसी भी अनुसूचित वादा कॉलबैक को टाइमर चलाने से पहले _before_ निष्पादित करने की इजाजत मिलती है।"। दुर्भाग्य से, मुझे जेस्ट एपीआई के माध्यम से clock ऑब्जेक्ट प्राप्त करने का कोई तरीका नहीं दिख रहा है।

किसी को पता है कि जेस्ट को हमें वह 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);
    },
  );
});

मुझे लगता है कि पिछला परीक्षण विफल नहीं होना चाहिए जैसा कि होता है।

मेरे लिए वर्कअराउंड वैश्विक "सेटइमीडिएट" के बजाय पैकेज "टाइमर" से नोड-देशी "सेटइमीडिएट" का उपयोग करके वादों को फ्लश करना था। इसके होने से, निम्नलिखित गुजरता है:

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

ध्यान दें कि कैसे आपको वादों को पूरा करने या टाइमर चलाने के बारे में कुछ भी जानने की आवश्यकता नहीं है।

@ जनसव अच्छा/+1। Fwiw मैंने उस दृष्टिकोण को देखा है जिसे आस्थगित पैटर्न कहा जाता है। मुझे लगता है कि यह अच्छे परीक्षणों के लिए बनाता है।

मुझे ऐसा लगता है कि नकली टाइमर के साथ समस्या यह है कि यह प्राकृतिक रन-लूप को तोड़ता है कि टाइमर को कैसे कार्य करना चाहिए। मुझे आश्चर्य है कि हम केवल जेस्ट टाइमर रन फ़ंक्शन एसिंक्स क्यों नहीं कर सकते हैं? समकालिक रूप से हल करने के लिए टाइमर बदलना परीक्षण कोड को साफ-सुथरा बनाता है, लेकिन यह इस बड़े दुष्प्रभाव का कारण बनता है।

मेरा उपयोगकेस:

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